Re: UT1 confidence
In message [EMAIL PROTECTED], Zefram writes: IERS Bulletin A gives an expression for the uncertainty of its UT1-UTC data predictions: S t = 0.00025 (MJD-today)**0.75 where today is the MJD of the bulletin's publication. The Bulletin only predicts a year ahead. Applying that formula gives an uncertainty a year ahead of 21 ms. The question is what domain of validity the above formula has ? In the builletin they only apply it up to 40d. For an argument of 10 years the result is 0.12 seconds. For an argument of 100 years the result is 0.66 seconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The Martian Chronicles
In message [EMAIL PROTECTED], Rob Seaman writes: Before somebody else calls me on it, I should point out that NTP actually uses both: The clock discipline algorithm functions as a nonlinear, hybrid phase/frequency-lock (NHPFL) feedback loop. (see http://www.cis.udel.edu/~mills/database/brief/clock) Let me just note that not all of us in the NTP environment belive that algorithm is optimal or even well understood. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], David Malone writes: FWIW, I believe most hospitals are more than capable of looking after equipment with complex maintenance schedules. It is not just a questoin of ability, to a very high degree cost is much more important. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Tony Fin ch writes: On Sat, 6 Jan 2007, M. Warner Losh wrote: OSes usually deal with timestamps all the time for various things. To find out how much CPU to bill a process, to more mondane things. Having to do all these gymnastics is going to hurt performance. That's why leap second handling should be done in userland as part of the conversion from clock (scalar) time to civil (broken-down) time. I would agree with you in theory, but badly designed filesystems like FAT store timestamps in encoded YMDHMS format, so the kernel need to know the trick as well. (There are other examples, but not as well known). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Rob Seaman writes: Warner Losh wrote: leap seconds break that rule if one does things in UTC such that the naive math just works POSIX time handling just sucks for no good reason. I've said it before, and I'll say it again: There are two problems: 1. We get too short notice about leap-seconds. 2. POSIX and other standards cannot invent their UTC timescales. These two problems can be solved according to two plans: A. Abolish leap seconds. B. i) Issue leapseconds with at least twenty times longer notice. ii) Ammend POSIX and/or ISO-C iii) Ammend NTP iv) Ammend NTP v) Convince all operating system to adobt the new API vi) Fix all the bugs in their implementations vii) Fix up all the relevant application code viii) Fix all tacit the assumptions about time_t. I will fully agree, that while taking the much easier approach of plan A, will vindicate the potheads who wrote the time_t definition, and thus deprive us of a very satisfactory intelectual reward of striking their handiwork from the standards, it would cost only a fraction of plan B. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2007-01-06T19:36:19 +, Poul-Henning Kamp hath writ: There are two problems: 1. We get too short notice about leap-seconds. 2. POSIX and other standards cannot invent their UTC timescales. This is not fair, for there is a more fundamental problem: Yes, this is perfectly fair, this is all the problems there are. And furthermore, the two plans I outlined represent the only two kinds of plans there are for solving this. They can be varied for various sundry and unsundry purposes, such as the leap-hour fig-leaf and similar, but there are only two classes of solutions. No two clocks can ever stay in agreement. This is not relevant. It's not a matter of clock precision or clock stability. It's only a matter of how they count. Yes, there is a cost of doing time right, and leap seconds are not to blame for that cost. They are a wake up call from the state of denial. Now, it can be equally argued, that leap seconds implement a state of denial with respect to a particular lump of rocks ability as timekeeper, so I suggest we keep that part of the discussion closed for now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Ashley Yakeley writes: Not necessarily. After seven months, or even after two years, there's a better chance that the product is still in active maintenance. Better to find that particular bug early, if someone's been so foolish as to hard-code a leap-second table. The bug here, by the way, is not that one particular leap second table is wrong. It's the assumption that any fixed table can ever be correct. So you think it is appropriate to demand that ever computer with a clock should suffer biannual software upgrades if it is not connected to a network where it can get NTP or similar service ? I know people who will disagree with you: Air traffic control Train control Hospitals and the list goes on. 6 months is simply not an acceptable warning to get, end of story. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: A lurker surfaces
In message [EMAIL PROTECTED], Zefram writes: Would have been nice. Actually, since the only real significance of GPS time is that it's part of the signal format, they could just as well have picked an unconventional but space-efficient encoding (say, 32-bit count of seconds, wrapping every 4 Gis). I think GPS time is best viewed as an encoding of TAI(GPS). I have been told by a person who should know better than to tell me such things that the choice of timescale in GPS is the result of unmitigated incompetence and the signal format is sheer stupidity. The fact that the UTC offset is in the Almanac instead of the Ephemeris means that almost all of the rapid response weapons cannot be used for tightly timed attacks until they have been primed with an almanac. He talked about the transmissions of the almanac being staggered between the satellites rather than in tandem, to reduce the mean-time to capture UTC-delta, but I did not find out if this was reality or plan. I guess one could use the raw-dump message to the Oncore and decode the almanac by hand to find out if this is the case. He also said that the quote in my .signature was used more often in Pentagon than he was comfortable with. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Peter Bunclark writes: Without the Moon, the Earth could nod through large angles, lying on its side or perhaps even rotating retrograde every few million years. Try making sense of timekeeping under such circumstances. You mean like taking a sequence of atomic seconds, counting them in a predicatable way and be happy that timekeeping has nothing to do with geophysics ? Yeah, I could live with that. Hang on a minute, statistically planets in the Solar System do not have a large moon and yet are upright; for example Mars comes very close to the conditions required to generate a leapseconds email exploder. As far as I know the atmosphere is far to cold for that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], John Cowan writes: Warner Losh scripsit: There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. So if I understand this correctly, there could be as many as 14 consecutive days during which |DUT1| 0.9s before the emergency leap second can be implemented; consequently, the current guarantee is only statistical, not absolute. But is it physically relevant ? Has anybody calculated how much energy is required to change the Earths rotation fast enough to make this rule relevant ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Tony Fin ch writes: On Tue, 2 Jan 2007, Warner Losh wrote: Curiously, BIH is currently, at least in the document I have, expected to predict what the value of DUT1 is to .1 second at least a month in advance so that frequency standard broadcasts can prepare for changes of this value a month in advance. There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. I was amused by the dates in http://hpiers.obspm.fr/eoppc/bul/buld/bulletind.94 That's an interesting piece of data in our endless discussions about how important DUT1 really is... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: A lurker surfaces
In message [EMAIL PROTECTED], Ashley Yakeley writes: M. Warner Losh wrote: GPS is also used for UTC today. Many ntpd's are stratum 1 tied to a GPS receiver. I imagine two parallel time infrastructures, one synchronised to TAI, the other to rubber mean universal time. Stratum 0 devices for the latter would probably have to use radio. This proposal is so patently badly researched that you should not talk more about it until you have _really_ thought about the implications, technical, scientifically and legally. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Steve Allen writes: McCarthy pretty much answered this question in 2001 as I reiterate here http://www.ucolick.org/~sla/leapsecs/McCarthy.html What exactly is the Y axis on this graph ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Steve Allen writes: One could say that it was never possible for the BIH/IERS to guarantee that its leap second scheduling could meet the 0.7 s and then later 0.9 s specification because they could not be held responsible for things that the earth might do. As such the IERS could conceivably start unilaterally issuing full decade scheduling of leap seconds and claim that it *was* acting in strict conformance with ITU-R TF.460. Considering that ITU has no power over IERS, IERS is only bound by the letter of TF.460 as far as they have volutarily promised to be, and consequently, they could just send a letter to ITU and say we'll do it this way from MMDD, if you disagree, then figure something else out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Magnus Danielson wr ites: From: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Re: [LEAPSECS] Introduction of long term scheduling Date: Mon, 1 Jan 2007 19:29:19 + Message-ID: [EMAIL PROTECTED] Poul-Henning, In message [EMAIL PROTECTED], Steve Allen writes: McCarthy pretty much answered this question in 2001 as I reiterate here http://www.ucolick.org/~sla/leapsecs/McCarthy.html What exactly is the Y axis on this graph ? Unless you have a subtle point, I interprent it to be in seconds even if they are incorrectly indicated (s or seconds instead of sec would have been correct). If you have subtle point, I'd love to hear it. Not even close to a subtle point, I simply cannot figure out what the graph shows... The sawtooth corresponding to the prediction interval raises a big red flag for me as to the graphs applicability to reality. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
In message [EMAIL PROTECTED], Rob Seaman writes: M. Warner Losh wrote: And avoiding the ugly 61 or 59 second minutes to define away the problem... It was the time lords who decreed that rubber minutes were prettier than rubber seconds. We're now to skip right over rubber hours to rubber days? Their aesthetic sense seems strangely malleable. It is not an æsthetic issue, it is an issue of practical implementation. In days no more than 100 clocks worldwide were precise enough to care about rubber seconds, they were acceptable. In days where no more than 1000 clocks worldwide were seriously affected by leap seconds, they were acceptable. In these days of heavily computerized infrastructure, we need more than half a years warning about discontinuities in the timescale. We can get that only by increasing the DUT tolerance. As Warner, I and others have repeatedly emphasized: It is not the step size that is the problem, it is the 6 month warning. I don't care if you want to implement leap-milliseconds, as long as you tell me 10 years in advance when they happen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
In message [EMAIL PROTECTED], Zefram writes: Ashley Yakeley wrote: In the Haskell time library, I represent UTC time by what seemed to me the simplest possible correct type. This is a record containing an integer to represent day number (as MJD), and a fixed-point decimal (picosecond resolution) to represent seconds since midnight. The allowed range for this is 0 to 86400.. That's a pretty good format. That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that the width can be adjusted to whatever precision and wordsize is relevant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Equitable estoppel
The BIPM says http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15RES=5 that UTC gives an indication of mean solar time, which it can only do using leap seconds. Steve, This is rubbish and you know it. UTC can give an indication of mean solartime with leap hours, leap minutes, leap-seconds or leap-microseconds, it's only a matter of precision. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: what time is it, legally?
In message [EMAIL PROTECTED], Daniel R. Tobias writes: http://gauss.gge.unb.ca/papers.pdf/gpsworld.january01.pdf One quibble with that article is that it gives the Global Positioning System as an example of how humanity has been obsessed with knowing what time it is. Actually, GPS arises from our obsession with knowing what *place* we're at; its need for precise time is a mere technical detail of its implementation. Absolutely not true. The original military requirements for GPS demanded timetransfer better then 10 microseconds for safe comms purposes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: how posterity will measure time
In message [EMAIL PROTECTED], Steve Allen writes: So it seems that when it comes to communicating a span of time to a civilization other than our own the solution that the best minds have produced is an astronomical one. The main reason for this is that the underlying charter specifically mentioned that one or more discontinuities in higher civilization must be expected. In that context, and because the problem is purely earth-bound, an astronomical solution seems to be a good idea. Although, likely as not, when some future arkæologist finds the inscriptions he will look at them without any formal training in any kind of physics or natural science and conclude that they probably have religious significance which is the default explanation in that branch of history. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: how posterity will measure time
In message [EMAIL PROTECTED], Rob Seaman writes: I'd vote, myself, for using a subduction zone for this purpose, Yes, that is the only scientifically appropriate response and I will, for once, vote with you. The interesting thing is, despite the fact that dumping it in a subduction zone has pretty much exactly the properties desired, including the amount of time before we risk seeing it back at the surface, nobody is talking about that disposal option. For reasons to convoluted to explain here, I have researched this exact question a fair bit, and the conclusion is rather sad: The material in question represents an enormous investment and contains a literal zoo of oddball elements, and therefore nobody can even contemplate throwing it away for good. All repository projects, throughout the world, have as a fundamental design requirement that the goods must be retrievable. As the Swedish project says: for when the next Einstein appears. Hopefully we will reach a time where the politicians responsible for the incomprehensible expenditures for nuke development in the cold war are out of power and saner heads will decide to take the garbage out where it is harmless. In the meantime, don't buy property near nuclear facilites. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: catching up, AAS and US Senate
In message [EMAIL PROTECTED], Steve Allen writes: On Tue 2006-09-12T23:18:05 -0700, Steve Allen hath writ: It appears that the version as reported in the senate in July struck out all of section 508. I could be wrong. I receive word that the UTC text still appears to be in Title V, and at the moment the link in the document seems to be named Section 2. It's still there in the PDF version, it's just not 508 anymore, it's moved up a couple of notches because other stuff were striken out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: PT Barnum was right
In message [EMAIL PROTECTED], John Cowan writes: Rob Seaman scripsit: Most troubling would be if two moving platforms are depending on GPS units with differing delays, e.g., two airplanes following neighboring flight paths. How far does an airplane move in 2 seconds? What is the minimum separation required by the FAA? Jetliners travel at about 550 mi/hr, or 246 m/s. Required horizontal separation depends on circumstances, but is rarely less than 3 miles = 4828 m. So if the discrepancy is 2 s, there is a safety factor of about an order of magnitude. Good enough. The ban on hand-held GPS for primary means of navigation is partly because of the worries about the slowness of updates. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: independence day
In message [EMAIL PROTECTED], M. Warner Losh writes : : That could sound like the drilling of a loophole :-) As has been pointed out in the past, the Secretary of Commerce has had the ability to define mean solar time to mean UTC (or something else, if they felt the urge)... I think this is just another attempt to keep their options open, like they have now... Yes, and no, mean solar time is something you measure whereas UTC is an international standard from a UN body which USA has ratified, so it makes sense to modify and interpret mean solar time, but not UTC. But yes, likely as not, this is not a black helicopter job, but rather sloppy or uninformed text-processing. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: independence day
In message [EMAIL PROTECTED], Steve Allen writes: In the middle of May some text about legal time in the US was introduced into a US Senate bill regarding funding for NSF and NIST. See section 508 of S.2802 introduced 2006-05-15, e.g. http://thomas.loc.gov/cgi-bin/query/z?c109:S.2802: `(b) COORDINATED UNIVERSAL TIME DEFINED- In this section, the term `Coordinated Universal Time' means the time scale maintained through the General Conference of Weights and Measures and interpreted or modified for the United States by the Secretary of Commerce.'. That could sound like the drilling of a loophole :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: building consensus
In message [EMAIL PROTECTED], John Cowan writes: Rob Seaman scripsit: Old English had its own set of month names entirely unrelated to the Latin ones: if they had survived, they would have been Afteryule, Solmath 'mud-month', Rethe[math] 'rough-month', Astron [pl. of 'Easter'], Thrimilch 'three-milking', Forelithe, Afterlithe, Wedmath 'weed-month', Halimath 'holy-month', Winterfilth '-filling', Blotmath 'sacrifice-month', Foreyule. At least some of these are obviously pre-Christian. They're practically all viking derived. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: ideas for new UTC rules
In message [EMAIL PROTECTED], Steve Allen writes: ==During the second five years after the date of adoption. (YA+5 through YA+9) On a semi-annual basis the IERS should publish an immutable schedule of leap seconds predicted for five years into the future. This would be a big improvement. Along with the five-year immutable schedule published monthly, the IERS should continue to publish the provisional schedule of leap seconds for the next ten years. I'm not sure I see how this is useful other than judging how well the predictions turn out. If you put a provisional table of leapseconds into your products and reality turns out differently, who is liable for the discrepancies ? Anyone can attempt to make their own provisional table already now, yet nobody does it or at least nobody has admitted that they do so, so I somehow doubt that it will catch on later. If you add 10 more leapsecond opportunities per year you will decrease reliability of the provisional table, compared to if there is only two opportunities per year. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: ideas for new UTC rules
In message [EMAIL PROTECTED], Rob Seaman writes: The reality is that the ITU-R specification is just a minor footnote pertaining to obsolete technologies of time signal transport. One presumes nothing would stop the IERS from publishing any scheduling algorithm such as you describe. Actually, since ITU is an UN institution and IERS is not, decisions made by former will take legal precedence over decisions made by the latter in most countries. The specification might benefit from dedicated IETF blessed IETF is not really relevant here, POSIX is, and that takes us into ISO territory, which means YAIO (yet another international organization) which also doesn't have a real mandate. (ISO standards only take effect if the national Standards Institutes bless/ratify/translate them.) Actually - one presumes the IERS currently has the authority to do both of these things. Have never heard anyone suggest that the next two leap seconds might not be announced simultaneously. And the ITU-R has already signed off on the monthly scheduling of leap seconds - this is the law of the land. What precisely is stopping us from implementing some variation of Steve's scheduling algorithm right now, today, this minute? All in favor, say aye! aye! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: ideas for new UTC rules
In message [EMAIL PROTECTED], Steve Allen writes:
On Fri 2006-04-14T09:43:45 +0200, Poul-Henning Kamp hath writ:
If you put a provisional table of leapseconds into your products and
reality turns out differently, who is liable for the discrepancies ?
It's a good question. My immediate response is that my notions are
also part of the
Full Time-Scale-Aware Lawyer Employment act of {YA}
I don't want us to adopt anything that makes that necessary.
If you add 10 more leapsecond opportunities per year you will
decrease reliability of the provisional table, compared to if
there is only two opportunities per year.
The motivation is that allowing ten more per year requires action on
the part of all systems to upgrade anything which now believes only
June and December (and they get ten years of notice to do so). More
importantly, it allows the IERS to react better to any surprises in
decadal fluctuations of LOD.
How does it allow IERS to react better if their horizon is defined
as five or ten years ?
Paraphrasing Westly in the fireswamps of The Princess Bride
DUT1 signals? I don't think they exist.
Well, I don't think anyone uses them. If there are still many
applications for DUT1 signals, most likely they are for sextant-style
navigation. If the leap seconds are being predicted five years in
advance then the annually published navigation almnacs can incorporate
projections which are as good as the broadcast signals.
Agreed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Re: An immodest proposal
In message [EMAIL PROTECTED], M. Warner Losh writes: [*] All variable radix counting conventions are insane by (my humble) definition :-). Off-topic: While not exactly variable radix counting, I read a book called A computer called LEO about the first commercial use of computers in the Lyons Tea Shops chain in the UK. One of the special gadgets that computer had was a multi-radix adder for dealing with the quaint coinage in UK at the time. The book is highly recommended. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: the tail wags the dog
In message [EMAIL PROTECTED], Rob Seaman writes: Quadratic despair still lurks, of course, since the month is lengthening for exactly the same reason as the day. Well, despair would be lurking if we tried to match the length of the month (a natural phenomenon) to an SI unit (such as the second). You mean the kind of despair where every so often we would have to put our finger on the scales to make them balance ? Ie: Just like when we match the length of the day/year to the SI second ? I think the crucial insight here is that geophysics makes (comparatively) lousy clocks and we should stop using rotating bodies of geophysics for timekeeping. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Markus Kuhn writes: A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Fixing POSIX time
In message [EMAIL PROTECTED], Neal McBurnett writes: On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote: Assign different timescales very different numeric epochs: TAI:1972-01-01 00:00:00 UTC For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. I chose the time when TAI became constant rate so that all the rubber seconds are confined to negative values. UTC:MJD's epoch. That would be midnight in Greenwich of 1858-11-17. I don't see the connection, and picking a time for which we don't know UT1 pretty accurately and authoritatively will cause all kinds of arguments. Well, any number will do, as long as the epoch is unique (also with respect to time_t. UT1:Flamsteads birthday ? Cute. 1646-08-19 NTP:defined in RFC1305 == 1900-01-01 It's all magic numbers and as such they don't have to give any meaning. We could just pull out a random number for each and define that as the value of the timescale at some particular well defined point in time, so it could be something like: at 2006-03-01 00:00:00 UTC the timescales will have the following values: TAI:N1 UTC:N2 UT1:N3 etc. Given that all the timescales count in SI seconds, that would leave a bit of math for people to build the conversion tables, but that could be a task to be done only once. I like giving magic numbers som kind of meaning though, if nothing else to honour birthdays of people who deserve it. Small platform implementations can use a smaller width, for instance 64 bits split 48/16 and easily transform to standard format by zero extension. That would work for 9 million years or so. Plenty, but the point is that bigger computers are multiple of 32 or these days 64 bits, so chosing 48 bits is just wasted space and trouble on those. Different epochs will make it painfully obvious when people mix but don't match timescales in low quality implementations. Now we just need a name for the proposal I _really_ don't care what it's called, as long as it's defined correctly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Fixing POSIX time
In message [EMAIL PROTECTED], M. Warner Losh writes: I like this idea as well... Poul, maybe we should implement this on FreeBSD. I'd suggest working_time_t or correct_time_t as the name of the type to replace time_t which would be deprecated. :-) plenty_time_t :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Rob Seaman writes: if you look at *any* form of PLL (circuit or software), then you will find that its very purpose is to implement rubber seconds, that is to implement phase adjustments via low-pass filtered temporary changes in frequency. An excellent observation. But missing the point entirely: We use PLL because we want to steer things to be synchronous, not because we see them as a means to implement rubber seconds. 1000 seconds is an incredible silly chosen number in an operational context. At the very least make it 15, 30 or 60 minutes. I would tend to agree with this. The Babylonians must have their kilogram of flesh. How about 10 minutes - 5 before midnight and 5 after? That's far to big a torque: 1. PPM Advantages: Sufficient resolution to represent any likely physical measurement or realizable frequency for the forseeable future (13.8e-18 seconds resolution). Any guess at likely physical measurements is going to fall short for some purposes. For one thing, one might want to represent theoretical values in addition to experimental. That said, you are likely correct for our purposes. Heisenberg, Bohr and Planck has a lesson for you :-) Now, please show some backbone and help solve the problem rather than add to the general kludgyness of computers. Do you find this tone of voice productive when collaborating? :-) You know, I've been in computing for so long that I have become alergic to kludges and quick fixes of all kinds. The worse and the more hackish they are, the more red spots I get. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Markus Kuhn writes: Now, please show some backbone and help solve the problem rather than add to the general kludgyness of computers. Been there, done that: http://www.cl.cam.ac.uk/~mgk25/time/c/ I remember looking at your proposal before and it suffers from a lot of problems. For instance it is pseudo-decimal while all contemporary computers are binary. This costs a fortune in performance and creates more coding mistakes than you can count. It doesn't have enough resolution for any of the people involved in serious timekeeping (NIST, BIPM, Timing.com etc) It is a two-part representation, which means that you face the silly problem that the C language doesn't give you access to the carry bit, but I guess that is really obscured by the use of pseudo-decimal. It also to some extent confuses representation and presentation which are two very different things. So while well intentioned, you simply didn't go far enough. My proposal tries to lay the groundwork for handling the entire problem way into the future, by extending the range both upwards and downwards and supports multiple timescales with enough room for another 250 accidents of standardization in that area. But I no longer think that any effort should be made whatsoever to expose real-world applications to the time value 23:59:60. That is not for us to decide really. (And my proposal doesn't address it btw, I'm only talking about the representation, not the presentation.) If the leap-seconds are here to stay, and unless heavy duty political power is brought to the issue by USA, that seems to be the case, we will have to get used to 23:59:60. And unless we handle it correctly, we will not be able to certify POSIX systems in a lot of critical applications in the future. Provided we define a convenient and sensible API for handling date time, 23:59:60 will not give people any more problems than any other time of the day, because it will be entirely handled by the library functions for timedate conversions. Poul-Henning PS: And this should not in any way be taken as a surrender on my part, I still think leapseconds are wrong in every way one can imagine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Tim Shepard writes: The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. As I learned from a recent posting to this mailing list, it seems that even TAI has rubber seconds (adjustments to the rate is made from time to time to compensate for errors that have been accumulating, making TAI a better (more useful) approximation time). Do you object to those adjustments (rubber seconds) to TAI as well? As long as the corrections are of the small magnitudes we have seen (10e-12 and below) and as long as they are applied to both TAI and UTC at the same time, I have no trouble with them. The reason I say 10e-12 is that only high end cesium and hydrogen units are affected by that in practice, everybody else can just ignore it. Remember, we can also risk other fundamental units needing an adjustment, the kilogram being in the high risk bracket here. This draft bugs me a bit because it changes the length of a second (as seen by its clients) by a rather large amount (a thousand ppm). A change in rate of ten ppm could accomplish the phase change with less than 1 day's warning before the UTC leap second insertion if accomplishing it could be split between the 50,000 seconds before UTC midnight and the 50,000 seconds after UTC midnight. But the half second delta to UTC is also a non-starter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: McCarthy point (was: Fixing POSIX time)
In message [EMAIL PROTECTED], Markus Kuhn writes: All I wanted to say is that for a good choice of epoch, it would be nice if we agreed on it not only to within a few seconds (the leap-second problem), but also to within a few milli- or microseconds (the SI/TAI second problem). The latter seems much easier to do for 2000 than for 1972 or even 1958. In applications such as observing planetary motion over many years, the difference matters. Good point. Presumably, the epoch will be defined relative to TAI or UTC to get maximum precision, so the limiting factor will probably be measuring (or having had measured) UT1 with maximum precision at the epoch. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] Markus Kuhn [EMAIL PROTECTED] writes: : M. Warner Losh wrote on 2006-01-19 19:20 UTC: : Effectively, you'd have to have two time scales in the kernel. UTC : and UTC-SLS. You make it sound simple, but the hair in doing this may : be quite difficult. There's more book for the kernel to keep, and it : would have to expose the bookkeeping to userland for ntp to work. : What makes this hard is that ntpd may introduce steers into the normal : system time at normal times which it doesn't want to confuse with the : steers in frequency that are used during a UTC-SLS operation. : : You correctly point out some of the design considerations that have to : go into such code. You describe roughly one of the (several) different : ways of implementing all this that I have in mind. In comparison to how : complicated the Mills kernel PLL is already today, that does not : actually sound like an overwhelming additional complexity. Actually, it : sounds quite doable when you think through it a bit. Not trivial, but : carefully doable without performance penalty. Anything that makes the Mills' kernel PLL more complicated is unlikely to be implemented correctly. Actually the Mills PLL isn't implemented correctly in the first place, The fact that the design is pretty baroque doesn't help. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Francois Meyer writes: On Mon, 16 Jan 2006, Mark Calabretta wrote: 1. UTC and TAI share the same rate, the same origin, the same second. And therefore : UTC - TAI = 0 This is wrong, plain and simple wrong. Please don't come back until you have understood and accepted that this is not the case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Report of Leap Second Problem with GPS Data
In message [EMAIL PROTECTED], Rob Seaman writes: I invite derision with my flights of rhetoric. As published papers [1] document, you have way to go. Poul-Henning [1] George August, Anita Balliro et all, study of Rotation of the Earth, approx 1993. (find it yourself). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: MJD and leap seconds
In message [EMAIL PROTECTED], Peter Bunclark writes: On Tue, 10 Jan 2006, Tom Van Baak wrote: have no leap seconds. Astronomers appear to avoid using MJD altogether. Good grief. MJD is used widely in astronomy, for example in variablility studies where you want a real number to represent time rather than deal with the complications of parsing a date. It tends to be written into the FITS header of practically every data file observed. So how do you deal with fractional days in that format ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: MJD and leap seconds
In message [EMAIL PROTECTED], Rob Seaman writes: 2. Julian Date (JD) [...] For that purpose it is recommended that JD be specified as SI seconds in Terrestrial Time (TT) where the length of day is 86,400 SI seconds. Let me see if understood that right: In order to avoid computing problems and to get precise time, astronomers rely on a timescale without leapseconds, because the Earths rotation is too unstable a clock for their purposes. And in N years, for some value of N, JD's will start at midnight instead of noon in Greenwich. Don't do like we do, do as we say... Yes, the irony is rather notable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: interoperability
In message [EMAIL PROTECTED], Steve Allen writes: On Mon 2006-01-09T08:20:40 +0100, Poul-Henning Kamp hath writ: beginning (SI seconds are constant length). Yes, SI seconds are constant length, but the ghost of my general relativity teacher prompts me to assert that my SI seconds are not equal to your SI seconds because we are in different reference frames. (This has nothing to do with leap seconds, [...] You are absolutely right there, so why even bring it up ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Clive D.W. Feather writes: The real problem is not the 23:59:60, it's *predicting* when they happen. I agree, the short prediction horizon is the major problem. But 23:59:60 _is_ a problem too. I don't think anybody dare even think about redefining POSIX time_t and even if they did redefine it to contain leap-seconds, many tons of software wouldn't be updated/recompiled to take advantage of it. So the standards crew, POSIX, LSB or whoever would have to come up with a new data type for holding timestamps, and while a number of proposals have been floated over the years, none of them seem to contain any real clue, so I don't think this is likely to happen. But pressume for a moment that they did come up with a new standard, the many tons of software would still not be rewritten to take advantage of it, so we'd still be stuck with time_t's ostrich behaviour for the forseeable future. Unlikely as it is, it would allow people like Warner and me to write software that Do The Right Thing. A far more sensible idea is to just forget about leap-seconds from now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary kind of service (internet services instead of handwritten letters), the astronomers to shut upcope and leaving the issue of the length of day in 500 years to the people who live 500 years from now on. It's the comparison between educating all programmers in the world vs having the astronomers use a DUT which is larger than 1 second. There is no doubt that from a humanistic point of view it would be better to educate all the programmers, but considering that I still suffer from web-forms that insist I enter a USA style phone number when I have entered Denmark as country, this is a far moure daunting task than it might appear. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: I don't think anybody dare even think about redefining POSIX time_t I wish people would stop making positive assertions about what other people are bound to think. What you mean in is, YOU are against suggesting changing (or augmenting) POSIX time. No, I mean exactly what I wrote: I don't think anybody dare even think about redefining POSIX time_t The reason I mean that is that I've talked to a lot of the relevant people and they're all totally morified about the consequences of (time_t % 86400) not giving you the time of day. Remember, most of these people are even afraid to extend time_t to 64 bits because of the possible fall-out :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Markus Kuhn writes: and you still cannot even get it reliably from your average local NTP server. This is a circular argument: The reason NTP doesn't provide it is that time_t needs UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Ed Davies writes: Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Since the usual response of the pro-leap second lobby to people who want a uniform timescale is use TAI this is significant. Do you have any information or references on why the BIPM director said this? As I understood it, it was mainly that TAI is a post-factum postal timescale. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The opportunity of leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: Something as simple as finger [EMAIL PROTECTED] Or even just a more stringent formatting of the bulletins on the ftp site could do it as well. I do not believe that any of the IERS bureaus have internet connections and servers which are anywhere near robust and redundant enough to make that a reliable service. There is a lot that could and should be done. I'm certainly starting to get the impression that a modernization project to move the time-lords a few decades forward would not be out of order. (Despite some NTP servers which reportedly still have not acknowledged the leap second, I think the overall indications are that the NTP network did better than 50 %.) My estimate is 50-70% of the pool.ntp.org servers did something close enough to the right thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year The Italian contribution to the November 2005 WP7A meeting could be interpreted a suggestion that the international agencies in charge of time scales need to get their heads together, pick one time scale with no discontinuities, and abolish all others. That sounds like the sensible partys platform to me. Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Klepczynski had implied that more clearly on pages 322 and 323 of http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf where he discusses getting all the satellite navigation systems to use a single time scale. It is the time scale that is the issue, it's the clock offset between the systems. If you have 2 GPS sats, one GLONASS and one GALILEO, you also need to know the clock offsets between the three systems before you can calculate a position. If everybody gets their act together and hold the clock offsets small, then it would be a wonderful world indeed, but I think the practical, organizational and political problems will prevent that. The other option is for the systems to broadcast their clock offsets relative to the other systems. For that to help rapid first fix it must be a frequent broadcast (ie: non-almanac) otherwise you might as well just wait until you get four birds in one system. (And to see that psychology is not just relevant to astronomers, read Matsakis on page 336.) Yes, astronomers have psychology too, but the comments on that page has nothing to do with leap seconds at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not? I didn't say I thought the protest against more widespread use made sense, I merely tried to relay it faithfully. I does sound consistent with previously mentioned old fashionedness. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The opportunity of leap seconds
In message [EMAIL PROTECTED], Peter Bunclark writes: On Sun, 8 Jan 2006, Poul-Henning Kamp wrote: finger [EMAIL PROTECTED] You mean [EMAIL PROTECTED] That would be quiet useful. Otherwise let's not bother with NTP protocol, just [EMAIL PROTECTED] I don't really care what the service is called, but I agree that it should be simple :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: interoperability
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Without further debating the meaning of civil time, consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. Yes, too bad about the offsets (GPS etc) but as long as they don't change with short notice, they can be dealt with. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Yes, just like now. The DCF77 transmitter for instance sends out German legal time which means that if you want UTC from it, you need to know the UTC offset for summer/winter in Germany. Governments and technical users would subscribe to the first stage clock. Businesses and civilians would subscribe to the second stage clock(s). Correct so far? Almost. What you overlook here is that computers tend to trancend governmental boundaries. Sensibly designed operating systems keep time in the form of the first stage clock, and at the representation layer, knowing all the worlds governmental decisions about getting from 1st to second stage applies the appropriate conversions. Badly designed operating systems keep time in local time which makes interchange of information a nightmare across timezones. Windows have got it right now I belive, but it used to be that a file created and transmitted from Denmark at the end of the business day would be older than a file created at the start of business day in California, despite a strict ordering of the events. For the sake of argument, let's discount the risks associated with confusing one stage's clock with the other. That's actually the good thing about the constant offset, it should make it much easier to see if timestamps mix things that shouldn't be. I won't belabor the many worldwide systems that must interoperate for the benefit of all. But these systems must interoperate not only between themselves, but with natural phenomena. Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. You mention sunrise and sunset. Since the introduction of timezones, one of the things which were given up was the concept that sunrise/sunset happened on the same numerical time at any given lattitude. Denmark spans only a few hundred kilometers from east to west (not counting Greenland this time), yet sunrise and sunset varies about 30 minutes from one side to the other. Most people get the sunrise/sunset numbers out of the Almanac from the Copenhagen Universitys Observatory [2] which lists sun rise/set times for the observatory in Copenhagen and prints a table of approximate geographical adjustment factors. So already today, sunrise sunset can only be determined using auxillary tables of correction factors, tables which could trivially absorb the DUT correction in addition to the longtude corrections. The question is: how precisely does this differ from the situation now or in the past? Whether by fiat or not, some common worldwide stage two clock must exist. BZZZT wrong. The definition we started out with is: The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Conversion from stage two to stage one (and back) is perfect, so if I measure a supernova in Denmark on Danish Civil Time, I can mail you my observations and you can convert it first to stage 1 and then to your local stage 2 to compare with your own observation. Or more likely, convert your own stage 2 to stage 1 and compare in the scientific time domain. If Denmark or Elbonia decides to use a timezone which is offset from stage one by 1h3m21s, then it still works, (but people travelling abroad will probably vote differently in the next election) I have heard no response to my discussion of techniques for achieving synchronization - of the difference between naive fall back hours and 25 hour days. But how in practice is it envisaged that a scheme for migrating time zones versus TAI would work, precisely? The same way all changes in timezone seems to be carried out: by _not_ adjusting the clock when going to summer or winter time. In a couple of hundred years, the Danish Parliament (or its successor in interest) will simply decide from -MM-DD HH:00, the Danish Civil time will use offsets -3h and -2h (instead of presently -1h/-2h) and the transition will happen on the switch from summertime to wintertime by _not_ adjusting the clock. That's been done many times throughout the world already. If you look in NPL's decription of the Rugby timegrams: http
Re: interoperability
is less disruptive than doing so, no matter which half of the year. (We'll omit discussion of the fact that not all localities observe daylight saving time in the first place.) They have 600 years to find a solution and an implementation date for it. ...but isn't what you are asserting precisely equivalent to saying that you are willing to support the issuance of one or more leap seconds - per day? If this will be more suitable a couple of thousand years from now - why not now? No, I won't entertain such a notion. I seriously plan to not be a nuisance to the world long before that. And I happen to think that my (n)great-children should get to decide for themselves about how to do timekeeping, and I am sure that they will think so themselves. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: interoperability
In message [EMAIL PROTECTED], Rob Seaman writes: As I pointed out close to five years ago, the ultimate long term remediation will likely involve redefining the length of the second: Rob, I think this shows how little you understand of the entire thing. Several SI units are defined relative to the second these days and therefore everybody involved in metrology have had nothing but contempt for the notion of changing the second length. To cut this part of the topic out in cardboard for you: 1. The Earths rotation and to a lesser degree its orbital motion are lousy timekeeping devices, many orders of magnitude worse than the best atomic frequency normals. 2. In metrology you use the best available method to implement a fundamental unit. But there is something else which bugs me. Throughout all of these interminable discussions it has become clear to me that you argue backwards from the end (there must be a UTC with leapseconds) rather than forward from the beginning (SI seconds are constant lengt). In our most recent little exchange, you started out proposing a two (or three) timescale solution without leap seconds, and then when I showed that it worked out just the way we wanted, you started to redefine the timescales so that one of them had to be UTC with leapseconds. You also keep harping about how day and night will switch places without leapseconds, while at the same time dismissing the governmentally defined local timezones as irrelevant, despite the fact that they do the heavy lifting (four orders of magnitude more than leapseconds) of holding the sun high in the sky at noon. In other words, you are not arguing in good fait and behave more like a religious zealot than anything else. That is deeply unserious behaviour of a scientist Rob. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message [EMAIL PROTECTED], William Thompson writes: Poul-Henning Kamp wrote: Universal Time = confusing term which comes handy when trying to manipulate discussions about leap second futures. I have to take issue with this one. My point was that when you just say Universal Time, how will we know if you mean UTC, UT0, UT1 or UT2 ? It's obvious from the current definition and terminology used with Coordinated Universal Time that the original intent was that UTC would be more-or-less synchronous with UT0, UT1, UT2. The current debate is whether we should move away from that original intent. Correct: we are talking about what the Leap(time) function should do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: UTC UTC(time) = TAI(time) + Leap(time) Owned by ITU. IERS evaluates Leap(time) according ITU definition Not quite. The endorsement for the usage of UTC comes from CGPM, and that is predicated on the existence of leap seconds. This is irrelevant. The CGPM may endorse which timescale they think should go into legal time, but if they change their mind UTC will still exist until ITU does something about that. A secondary issue is that even if CGPM decided to say Use FOO instead nobody would take much notice until ITU and a lot of other people agreed and did their respective paperwork. But in the original agreement, UTC and TAI were defined solely by the BIH according to the rules of the CCIR. Both the BIH and the CCIR are defunct. TAI was transferred from BIH to the BIPM. Determination of the UTC offset was transferred from BIH to IERS. But IERS is not a single entity, it is an ensemble of entities. Lets waste a lot of time splitting red tape, why don't we ? At the beginning of 1984 and at the beginning of 2003 the branches of the IERS responsible for UT1 followed new IAU recommendations and changed the rules by which UT1 is calculated. The current version of UT1 has a notably different flavor and long-term purpose than the version of UT1 which was in place when UTC with leap seconds was originally defined by the CCIR. But that matter, because ITU-R (successor of CCIR) defined Leap(time) in terms of UT1 without specifying how UT1 was arrived at. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Michael Sokolov writes: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: At the beginning of 1984 and at the beginning of 2003 the branches of the IERS responsible for UT1 followed new IAU recommendations and changed the rules by which UT1 is calculated. The current version of UT1 has a notably different flavor and long-term purpose than the version of UT1 which was in place when UTC with leap seconds was originally defined by the CCIR. doesn't v But that matter, because ITU-R (successor of CCIR) defined Leap(time) in terms of UT1 without specifying how UT1 was arrived at. oops... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
HBG transmitted wrong info during leapsecond
Looks like the inserted the leapsecond after the minutemarker: http://phk.freebsd.dk/Leap/20051231_HBG/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: HBG transmitted wrong info during leapsecond
In message [EMAIL PROTECTED], Markus Kuhn writes: Which was also noted at http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html Right, but I think my data has a bit more resolution etc. I'm demodulating Rugby right now (will take half a day or so) and after that I'll go after France Inter's phase modulation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Ed Davies writes: Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: Wrist Watch time Wall clock time Grandfather clock time Tower clock time Television time Embedded system time Appliance time Router time PC time Windows server time Commercial UNIX time Free UNIX time Main-frame time and give each of them their own unique way of coping with leapseconds ? Ohh wait... That's what it looks like today already isn't it ? :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Ed Davies writes: Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. I have no problems with different timescales for different purposes. For instance I very much wish the Astronomers would start to use UT1, which is very much their timescale, and stop abusing UTC, which isn't, as a convenient approximation. But I have big problems with people who want to introduce more timescales without thinking through the legal and technical complications. The question is, where in the range of possible timescales is it most useful to put civil time. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a computer time scale in a pathetic attempt to paste over leap seconds. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The opportunity of leap seconds
In message [EMAIL PROTECTED], Rob Seaman writes: Astronomers use UT1. Astronomers use UTC. Astronomers are among the biggest users of TAI and GPS and likely any other timescale you care to name. And they certainly have a lot of trouble seeing the rest of the world in for the brightness of their own majesty. The only timescale I am interested in here is UTC, and astronomers are not even close to registering as a marginal group in the user communities of UTC. What Astronomers use UTC for, in your own many times repeated words, is a convenient approximation of UT1, and consequently it follows that if instead of an approximation astronomers used the Real Thing, leap seconds could harmlessly be removed from UTC. By your logic, the U.S. Surgeon General should be a chiropractor. Once the US government tries to shoulder their national deficit that would undoubtedly be a good idea. [various ramblings] Canoli = common basis for diverse time usage worldwide Eclair = baseline representation of Earth orientation Unless we *completely* change our notion of Canoli, Canoli is tightly constrained to follow Eclair simply by the fact that today and tomorrow and the million days that follow are all required to be dark at night and light in the day. Wrong on all points. Light of day and darkness of night already is, and for all relevant future can be, assured by governmental adjustments of the two functions government control in the formula: Civil Time(time) = UTC(time) + TimeZoneOffset(country, subdivision, time) + SeasonalOffset(country, subdivision, time) [various ramblings] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Neal McBurnett writes: Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Yes again. And they are free to choose TAI if they want a uniform time scale. But why take the choice of a UTC that remains within 0.9s of the earth's average rotation rate? Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. The snippy answer to why UTC was adopted for civil timekeeping would be Because they got bad advice, but that would be grossly unfair since nobody (but possibly Dave Mills) at that time could be expected to foresee what computer networks would result in and how that would affect the needs for timekeeping. Just like the variable rate atoms of the sixties where a bad idea we now know that the variable length days that replaced them are bad. I'm not old enough to have any axe to grind about the last couple of redefinitions of time, but I can see where they both went wrong (insisting on using the unprecise and unstable clock to discipline the stable and precise clock) and I want us to stop that mistake. Here we disagree. I guess you're confirming what is in fact the current problem as I see it. We're here because an ITU committee, shrouded in secrecy, is trying to redefine UTC and the international distribution of time signals, which most jurisdictions rely on one way or another as civil time. But you overlook that ITU is an international organization under the UN aegis. If ITU in their plenary assembly decides to do something, no matter how stupid, (X.400 for example), that is nontheless the will of the governments of the world. You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. I will agree that a lot of what ITU churns out, UTC with leapseconds and X.400 being my best examples, are rubbish. Some folks here suggest that legislatures just change their timezones periodically, forced by the actions of the ITU. But data was presented in Torino suggesting a cost to NASA and US DoD of a half a billion dollars to study, re-engineer and test their systems if UTC diverges markedly from UT1. Not an easy thing for a legislature to deal with. Again - it's a process problem Let me channel something that gets said a lot here: They should have used the right timescale from the beginning. It sounds like they should have used UT1, doesn't it ? And why is it that IT related costs matter so much if they come from people worried about the effect of lack of leapseconds, while at the same time, they don't matter at all if they come from people worried about the effect of leapseconds ? Clearly what's good for the goose is good for the gander, right ? The only time there has been an inclulsive international meeting devoted to the issue, at the colloquium in Torino, There was no overwhelming consensus on whether the status quo should be maintained or an alternative should be pursued. ... at that meeting. The only consensus that matters is the ITU-R SG7A, which coincidentally didn't reach one either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. You can try that, and you may succeed, but it is deceptive to assert that is easy to do. As far as I know, pretty much anybody can get observer status in the working group for a modest/outrageous (take your pick) amount of money. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. Agreed, you just have to be prepared to play the Byzantine games. Well, that's politics for you. Just because one doesn't like the rules doesn't mean that they're not fair. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
DCF77 leapsecond documented
My VLF/LF capture has started to yield information now. I captured the antennasignal from my home-brew loop antenna (http://phk.freebsd.dk/loran-c/Antenna/) with an Adlink 9812 ADC card at 12 bits and 5 million samples per second. In total I have 400GB of capture, almost 8 seconds around the leapsecond. Some crude software-radio and some CPU hours later, here is the DCF77 behaviour during the leapsecond: At midnight, local time the leap warning bit is turned on: v 24410.639 001011100101011000111000110110100110101 23:53 0 24470.639 00101001010000111000110110100110101 23:54 0 24530.639 001011010101011000111000110110100110101 23:55 0 24590.638 001010110101011000111000110110100110101 23:56 0 24650.638 0010010000111000110110100110101 23:57 0 24710.638 00101000110000111000110110100110101 23:58 0 24770.639 001011001101011000111000110110100110101 23:59 0 24830.639 001010001001101 00:00 0 24890.638 000010001001101 00:01 1 24950.638 0011101010001001101 00:02 1 25010.638 00101001101 00:03 1 25070.639 0011100110001001101 00:04 1 25130.639 00011001101 00:05 1 25190.639 001110111001101 00:06 1 25250.638 001110001001101 00:07 1 And at 00:00 UTC the leapsecond happens and the leap warning bit turns off: 28010.639 001001011001101 00:53 1 28070.639 00111001010110001001101 00:54 1 28130.638 000101011001101 00:55 1 28190.638 0011101101011001101 00:56 1 28250.638 0011010110001001101 00:57 1 28310.639 00111000110110001001101 00:58 1 28370.639 000011011001101 00:59 1 28430.638 0011110110011010 01:00 1 28491.639 0010110011011001101 01:01 0 28551.639 0010101011011001101 01:02 0 28611.638 0010111001011001101 01:03 0 28671.638 0010100111011001101 01:04 0 28731.638 0010110101011001101 01:05 0 28791.639 0010101101011001101 01:06 0 28851.639 001011011001101 01:07 0 The first column is the number of seconds into the capture data and you can also see the extra second going from 28430.638 to 28491.639 Rugby and HBG and France Inter will follow in the coming days if I can get my software to decode them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message [EMAIL PROTECTED], Rob Seaman writes: Perhaps what we need is simply to define our terms. A lot of the friction on LEAPSECS undoubtedly comes from conflicting meanings. Good point. Civil Time = the common basis for diverse time usage worldwide No. Civil Time is a legal term, and you have no power to redefine it. Civil Time = Legal Time = what the applicable law says the clock should show. Solar Time ~ Mean Solar Time ~ Universal Time ~ GMT ~ UTC ~ UT1 = various approximations to the baseline of Earth orientation No, No, No. Solar Time ~ Mean Solar Time ~ UT1 = various astronomical/geophysical concepts. GMT = Legal time in the UK, defined by parliament. UTC = Standard defined by ITU-T, based on SI seconds. Universal Time = confusing term which comes handy when trying to manipulate discussions about leap second futures. Standard Time ~ Local Mean Time ~ Local Apparent Time ~ Sidereal Time ~ Daylight Saving Time, etc = not pertinent to our discussion (Partially) Wrong again. Daylight Saving Time is a component of Legal time and very relevant to our discussion. So lets try again, and let us focus on only the bits we need to look at: TAI TAI(n) = TAI(n - 1) + 1 SI second Owned by BIPM / Metre Convention UTC UTC(time) = TAI(time) + Leap(time) Owned by ITU. IERS evaluates Leap(time) according ITU definition Civil Time(country) Civil Time(time) = UTC(time) + TimeZoneOffset(country, subdivision, time) + SeasonalOffset(country, subdivision, time) Owned by government of country. Some politically backwards countries like Denmark have not after a century managed to get their laws aligned with reality, but that is merely a matter of political unexpediency. At this level we don't need to look at UT1 or any of the other timescales. 99.999% of the Earths population only see those manifested as hidden variables in the Leap(time) function. So what we are discussing here is only the Leap(time) function. You will notice that this function has one argument only: time. As surprising as this may seem, that is actually the way it is. Leap(time) is a function that is defined as evaluating to an integer number of SI seconds as a function of time and it is defined piecemal with a horizon of 6 to 12 months from the present. Once IERS have made up their mind, the function doesn't change again, even if we find out that Earth Orientation was different from what they thought it was. Behind the scenes, IERS uses UT1 to decide how Leap(time) develops because that is how ITU defined the function, but that is a hidden process because nobody can evaluate it definitively apart from IERS. If you look at the functions TimeZoneOffset(country, subdivision, time) and SeasonalOffset(country, subdivision, time) You will find that with a margin of a couple of hours to both sides their values tend to make the statement sun highest in the sky at 12:00 true. This trend is of course not accidental. You will also appreciate that should the relevant governments feel the desire, they can redefine both functions without consulting anybody but the citizens of the country in question. If in a hypothetical scenario, the citizens of country N notices that because of continental drift, stupid politicians or the way the UTC timescale is defined, the sun doesn't tend to be highest in the sky around noon, they are perfectly free to elect some politicians who with what goes for sufficient warning in that country can redefine the two functions to make it more so. Now tell me why you think Leap seconds are so important again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Longer leap second notice
In message [EMAIL PROTECTED], Rob Seaman writes: Hi Warner, A more apt comparison would be to the leap year rules that we have. We know the rules going forward a thousand years or so. Apt indeed. Leap seconds are scheduled at least six months in advance. That's about one part in 15 million. A thousand year horizon for scheduling leap days is one part in 365,250. So we're already doing 50 times better than Julius Caesar and Gregory XIII. This comparison is utter rubbish, and you know it. Little support - and again, to a certain level of precision (easily better than a second per day), all parties must certainly agree that civil time (as we know it) IS mean solar time. Since you keep repeating this Nixon cannot have won, nobody I know voted for him falsehood let me express myself in very simple terms: No, I do *NOT* agree that civil time is mean solar time. Got it ? Civil time is at best local solar time +/- up to several hours in either direction depending who you are and where you are. Seveal geographical/political regions have actively chosen to increase the distance between mean solar time and local time during various stretches of time, often in periodic fasion and sometimes with far too little thought before the decision. We keep hearing use an appropriate timescale and in the same emails we hear UTC is a convenient approximation of UT1. Sounds to me like that argument should be backfired: If you need UT1, then use an appropriate timescale: UT1, don't force the majority of UTC users to suffer because you use the wrong timescale. Can't argue with that - although ultimately a single well tied knot is stronger than a tangle of slip knots and Grannies. We're not talking about knots here, this is not cryptography, we are talking about byzantine decision scenarios (I have three references, one say leap second, one says no leap second and one says nothing, what should I do ?) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Diagram of CHU Leap-Second Recording and Atomic Clock
In message [EMAIL PROTECTED], Tom Van Baak writes: As for your Skyscan clock, I have several dozen similar consumer RC clocks here and none has ever adjusted itself for a leap second in real-time The majority of such clocks only run the receiver for some part of the day to save power. One particular kind I examined ran the receiver until it had sync, then powered the receiver down for 23 hours and repeated the cycle. My local clockaholic told me that some of the more modern ones sleep based on battery voltage: As the voltage drops, the chance of slips in the mechanism increases and the receiver will turn on more often to make sure it is still in sync. In the case of DCF77, that means that you'd have to be rather lucky for your clock to do the leapsecond in real time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: civil time = solar time
In message [EMAIL PROTECTED], Rob Seaman writes: I said: all parties must certainly agree that civil time (as we know it) IS mean solar time. Ed says: saying that it IS civil time is probably a bit strong. Probably a bit strong is not precisely a staunch denial. [...] This is simply a classic exercise in applying epsilon constraints. Yes, another inappropriate method used to sell your bogus argument. It's bogus because neither local time nor civil time is a continous variable but a quantified variable (because of the timezones) The minimum epsilon constraint which is valid for a quantified variable is the unit of quantum. That is why all digital measurements by definition have an uncertainty of at least +/- 1 digit. The longitude conference defined the unit of quantum as 1 hour but despite this I belive a few localities (.au ?) have opted for a 30minute quantum. 1. local civil time matches apparent solar time roughly Because local civil time have chosen timezones appropriate for this purpose. 2. the relationship between local civil time and apparent solar time is constant enough in any one place Uhm no. Politicians have decided to make it flip 15 degrees forth and back with summertime regulations. 3. the rate of local civil time is constant at least to the precision of most clocks and watches. This is a rather empty statement because most clocks and watches are built, sold, bought and adjusted to show civil time. 4. the relationship between local civil time and international civil time should be predicatable and easy to calculate with Which is why the longitude conference decided on a 1 hour quantum. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Where the responsibility lies
In message [EMAIL PROTECTED], Rob Seaman writes: John Hawkinson replies: I think PHK has demonstrated the ability (and willingness :-) to hold up his own end of an argument. Should we ever find ourselves at the same conference, I'll buy him a beer in anticipation of a rousing discussion. I'll be happy to bring booze as well :-) There are several issues confounded here. First, an untested assertion that eliminating leap seconds will simplify time handling. DUT1 looms large in astronomical software and one would have to be convinced that this is not an issue with other disciplines. But it's exactly the fact that DUT1 already exists that bugs me. If you already have to cope with DUT1 anyway, how much difference can it possibly make if the definition says |DUT1| .9 or |DUT1| 10sec or |DUT1| 1 hour If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Third, leap seconds are a mechanism to realize mean solar time in practice. As would leap-hours (or jumping timezones) be. It's only a matter of the tolerance we accept on DUT1. As far as I know, less than 1% of people on this planet actually have the sun straight south at 12:00 local time today and a quite sizeable minority (a lot of China) lives perfectly happy with the sun being further than 15 degrees from south at local 12:00. It follows from this, that a proposal for a 1hour tolerance on DUT1 is perfectly feasible without odd things happening to the cows milk etc. The acknowledgment of a contingent need for leap hours shows that the authors of the ITU proposal understand this. I think the leap hours is a political tool to make the proposal go through without commiting anybody to anything for the next couple of hundred of years. Fourth, the need for leap seconds is growing quadratically as the Earth continues to slow. We have no business making ad hoc policies based on the rarity of events that are becoming more frequent. The need for leap hours will grow just as rapidly - and much more dramatically. A solution that ignores real world constraints is no solution. Uhm, no. There are three orders of magnitude difference between a leap second and a leap hour, and consequently the need for leap hours will grow less rapidly than the need for leapseconds. In short, leap hours are - well - dumb. A proposal that relies on their use, naive. Leap hours or leap seconds is only a matter of magnitude and frequency and consequently both are equally naïve. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Longer leap second notice, was: Where the responsibility lies
In message [EMAIL PROTECTED], Ed Davies writes: Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. PHK can reply for himself here but, for the record, I think RS's reading of what he said is different from mine. My assumption is that PHK is discussing the idea that leaps should be scheduled many years in advance. They should continue to be single second leaps - just many more would be in the schedule pipeline at any given point. Obviously, the leap seconds would be scheduled on the best available estimates but as we don't know the future rotation of the Earth this would necessarily increase the tolerance. In theory DUT1 would be unbounded (as it sort of is already) but PHK is assuming that there'd be some practical likely upper bound such as 10 seconds. Am I right in this reading? yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Where the responsibility lies
In message [EMAIL PROTECTED], Neal McBurnett writes: On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Do you have any evidence for this assertion? It is an educated guess. The IERS have already indicated that they belive they could do prediction under the 0.9 second tolerance with two or three year horizon. Anyone have a prediction algorithm in mind, and a result of running it on the last several decades or centuries of data? Makes a great subject for science, doesn't it ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: NTP behavior in Australia
In message [EMAIL PROTECTED], Steve Allen writes: Here is one indication of NTP response to the presence of low stratum servers which did not behave well. http://members.iinet.net.au/~nathanael/ntpd/leap-second.html I grabbed a set if IP#'s from pool.ntp.org and monitored them in the 24 hours before and 8 hours after the leap. Out of a set of 12 IP#'s two public stratum 1 servers never set the leap bit, but did apply the leapsecond locally. One of the 12 was a stratum 1 using DCF signal, and that one as expected only set the leap warning one hour before the event. Ten hours after the event, two stratum 3 servers in the set still had the leap warning bits set. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
text book example why Leapseconds are bad
http://lheawww.gsfc.nasa.gov/users/ebisawa/ASCAATTITUDE/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Software requirements
In message [EMAIL PROTECTED], Daniel R. Tobias writes: On 21 Dec 2005 at 21:33, Poul-Henning Kamp wrote: I suspect more real world computers are in roughly this situation as opposed to being absolutely dependent on being correct to the millisecond or microsecond at all times; the system clocks of practically all computers are just not sufficiently accurate for that. If computers start having an actual atomic clock on board, maybe things will be different. The trick is how you efficiently and precisely determine which computers do and which do not need to cope correctly with leapseconds, and subsequently, how you determine which of the ones that need to, will do so. Y2K has shown us that just ask people is so far from the correct solution that it is almost better as a negative indication. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Schreiver AFB warns about leapsec
In message [EMAIL PROTECTED], Francois Meyer writes: On Tue, 20 Dec 2005, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED] on.fr, Francois Meyer writes : I second this too, 23:59:59 is the worst time to insert a leap second, since failing to implement it leaves you with the wrong day (month and possibly year) at the very second it occurs. That is probably one of the strongest arguments for retaining that moment of insertion: That way computer bugs are more likely to be noticed. UTC is not a debugging tool, it is an international standard. Software is an an issue but I think it cannot justify in itself that leap second impact should be as large as possible. It must be wonderful to live in a world where software can just be ignored or marginalized at whim, I really envy you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Schreiver AFB warns about leapsec
There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS support center: https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/Leap_Second_Event.ppt Amongst the nuggets: Large error makes data unusable for some applications Eglin radar missed the leap second in 1998 Thousands of observations had to be discarded Problem was also evident at Clear However, host system software receiving the 23:59:60 time hack may not know what to do. System dependent response. They clearly know what the problem with leap seconds is :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Lighter Evenings (Experiment) Bill [HL]
In message [EMAIL PROTECTED], Markus Kuhn writes: The crudest approach would probably be I would be all for it :-) a) N+S America: use local time of Cuba (~ UT = - 5.5 h) Unless you substitute something other than Cuba, your proposal will never get one inch of traction in USA. And of course, that is the crux of the matter: such decisions have more to do with politics than science or even reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: a system that fails spectacularly
In message [EMAIL PROTECTED], Rob Seaman writes: On Dec 7, 2005, at 11:57 AM, Poul-Henning Kamp wrote: ISO9000 certification only means that you have documented your quality assurance process. There is no requirement that your documentation pertains to or results in a quality product. That was kind of my point, too. We have standards bodies that don't promulgate their standards. [...] You need to look even further down the foodchain, starting from the bottom: * First comes people who make buying decisions based on price. * Then comes engineers who are only in it for the money. * Then comes product managers cutting corners to push out a cheap product early. * Then comes companies who only care about money The kind of people who even care enough to think about participating in standards writing, are leagues above those four by the simple fact that they actually do care in the first place. And as we all know from the standards we work with, even those people are pretty underperforming to begin with. In an ideal world, I would love to educate them all about the errors of their ways, but I'm too old to seriously contemplate such a project. Leapseconds are simply too technically tricky for the species we are dealing with. They are OK if confined to science labs, but out in the real world where people think McDonalds food does not make you fat leap seconds are just no feasible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: a system that fails spectacularly
In message [EMAIL PROTECTED], Brian Garrett writes: And you've gotta love the interpretation of UTC as Universal Time Code in the Canadian report. If they don't understand what UTC is, or at the very least understand that their users are going to be confused by their misleading use of the acronym, it's hardly a surprise that a leap second is going to pull the rug off their code and expose the bugs they've swept underneath it. Some of us have been trying to drive this point though for some time: 99.99% of all programmers have no idea what a leap-second is. And these are the people who program the technology that runs our civilization. Think about it next time you press a button. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: BBC - Leap second talks are postponed
In message [EMAIL PROTECTED], Rob Seaman writes: On Nov 21, 2005, at 1:53 AM, Clive D.W. Feather wrote: It is NOT CALLED daylight saving and it is NOT saving any daylight. I don't know where you are, but in Denmark we gain close to 60 minutes extra daylight per day except for june/july, so we do in fact save the daylight for better use. It is summer time. Ok, then. Anybody have a suggestion for a general term for which daylight saving and summer time are special instances? Well, local languages have their private definitions, in Denmark it is summertime/wintertime. The Danish version talks about UTC, which is cute since in Denmark legal time is still mean solar time at the Copenhagen Observatory, How does this work in practice? Lots of web hits show Copenhagen in the Central European Timezone, one hour ahead of Greenwich (ignoring the whole summer time issue). Its longitude appears to be 12.66 degrees east, or 50 minutes ahead. Of course we use the same time as everybody else around us, (UTC + 1h/2h) but legally that is approx 14 minutes and 33 seconds wrong. In all likelyhood, a lawyer would point to some international convention or other about time (the meter convention, or some UN/ITU related thing) which has superseeded the old law, but on the book, it is wrong. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: WP7A press release
In message [EMAIL PROTECTED], Rob Seaman writes: The attached WP7A press release states that the working party has decided that more time is required to build consensus. It does not, however, suggest that any other proposals will be entertained. Neither does it in any way bar new proposals. I don't think there is even anything in the WP7A rules that would allow them to bar new proposals, provided these were submitted properly. But I think you read their message wrong. I don't think they said We'll try to build concensus. As I read it, they more or less told USA that their proposal was nice and all that, but that since it did not come with a concensus or majority, they ain't going to touch it. The to weight, as I understand it, is therefore on USA and the leap-second aware computer people. With respect to the secrecy and lack of awareness of the ITU standards I can only agree: IETF proved that standards work a lot better when anyone easily can get hold of them and everybody can afford to read them. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: International Conference on Civil Timekeeping (was Re: [LEAPSECS] WP7A press release)
In message [EMAIL PROTECTED], Rob Seaman writes: On Nov 18, 2005, at 5:21 AM, Poul-Henning Kamp wrote: As with any consensus-building, the weight is on whoever would like to see such emerge. For instance, just by debating the issue, the ITU is asserting that they own the UTC standard. Is this actually the case? I suspect that a squadron of lawyers would likely find that the International Telecommunications Union is the appropriate international body to transport time signals relating to, well, international telecommunications - but what exactly is that? Clearly other time signal providers exist, e.g., GPS and NTP. But who owns the underlying concept of Universal Time or the UTC flavor of same? Perhaps this is the first consensus position to identify. (Along these lines I find it a far more interesting question who owns the leap-day formula. Is it still the pope ? :-) I see neither reason nor advantage to move UTC from ITU which is an UN body where all citizens of the planet have a voice to a semi-closed priesthood like IERS or BIPM where only scientists have a voice. In particular not given that these particular scientists seem to be very behind the curve when it comes to modern technologies like data/tele networks etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: BBC - Leap second talks are postponed
In message [EMAIL PROTECTED], Peter Bunclark writes: On Fri, 18 Nov 2005, Ed Davies wrote: On the other hand, I rather snigger at the reservation of the word universal to mean time based on the Earth's rotation. It's all rather parochial but it is the established terminology. Doesn't Universal hint at the join of the SI second and Solar Time? Oftentimes labels of X are put on things to give the impression of a good bit more X than is actually at hand. I suspect that Universal in UTC has the same lineage as democratic in The Democratic Republic of Congo. UTCs proper name would have been ITC, International Time Coordinated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
In message [EMAIL PROTECTED], Steve Allen writes: The inclusion of calendar year is an interesting addition to the original week-based scheme. The week-based scheme was perhaps chosen while noting that the week remained intact when Pope Gregory (and then, eventually, all the protestants) switched calendars. I think you are far overestimating 1970 electronics :-) The week based scheme was a compromise forced by number of bits available and how much electronics could be dedicated to the task of receiving the signals. For a long time the almanac was something you had to manually enter into the receive (which is probably why almanacs are still published by the GPS control segment people). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 26 Sep 2005, Poul-Henning Kamp wrote: On the other hand, even if we agree on one standard, or even just leave UTC as it is, are the astronomers and geophysiscists going to abandon UT1 ? If so, then this is the first I've heard about it. Of course not. And that was exactly my point: civil and scientific timekeeping was two different issues and they have different semantics and needs. Most of this argument is still centered around the unarticulated question: who owns UTC. Wouldn't it be fair if the non-scientific (ie: civil) world told the astronomers (and any other scientists) to bugger off and not impose scientific requirements on civil time ? After all, scientists have several timescales of their own already, and plenty of means to implement them, whereas UTC is the only agreed upon and widely available civil timescale. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: RAS hits the news
In message [EMAIL PROTECTED], Tom Van Baak writes: I am wondering, though, if anyone knows of an example of a GPS receiver that caches the delta value from the last power-up? It seems to me this would take care of the delay in all but the most extreme cases. Most receivers will cache the almanac if they have a piece of CMOS RAM for it. The Oncore series certainly do. But appearantly the Oncore only uses the Almanac to get a quick first fix when you power it back up, and for this even a quite old almanac will do since in general the orbits are quite stable. The Oncore doesn't seem to trust the cached/uploaded almanac beyond that, until it has received confirmation that it is indeed the current almanac. I'm not quite sure what confirmation it takes to satisfy the Oncore on this point, but it looks like it is the specific sub-frame of the almanac which contains a timestamp of some sort, because it takes from up to twelve minutes to happen, but it does not coincide with the @@Cb return of the newly aquired almanac. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Daniel R. Tobias writes : On 26 Sep 2005 at 16:09, Poul-Henning Kamp wrote: Other more laid back parliaments like the Danish have not been able to find time to revisit the issue since 18xx and still use solar time at some more or less random coordinate. You mean like the U.S. Congress? http://tycho.usno.navy.mil/260.html ...the standard time of the first zone shall be based on the mean solar time of the sixtieth degree of longitude west from Greenwich... (and so on for all the other zones) Well, at least they had the sense to use a longitude divisible by 15. Not so lucky in Denmark: 50°19' Imagine for instance that we send a probe out of the solar system at seriously high speeds and it manages to get as far as 6 light months away: Under the current UTC rules we would be unable to upload a leap-second warning and get it there before it is too late. I would suppose that such a space probe would have little need to be synchronized with earthly solar time, and thus might be best off operating on TAI, with any adjustments to UTC for the sake of humans observing it on Earth being done at the Earthly end of things. Again: merely trying to point out that the only one timescale argument Rob pushes doesn't work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Comments on Civil Time decision tree
In message [EMAIL PROTECTED], Randy Kaelber writes: On Mon, Sep 26, 2005 at 02:33:00PM -0400, Daniel R. Tobias wrote: I would suppose that such a space probe would have little need to be synchronized with earthly solar time, and thus might be best off operating on TAI, with any adjustments to UTC for the sake of humans observing it on Earth being done at the Earthly end of things. That's the way we do it for interplanetary stuff now. Data from spacecraft are typically returned in spacecraft clock time (SCLK, which is pronounced sclock) and then translated to whatever time base you want it in. Right now, the clock on Mars Odyssey (as I type this) should be reading 2/0812228033. Dealing with things like leap seconds, local time conventions, and other time conversions are all handled here on Earth. But that strategy breaks down for human space flight ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
In message [EMAIL PROTECTED], John.Cowan writes: Rob Seaman scripsit: [B]ut we already agree on a common position that civil time needs to mimic solar time for most purposes. Kashi, Kashi, Kashi. It's interesting that no matter how much we keep telling him otherwise, Rob still claims that we already agree on the above statement. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
In message [EMAIL PROTECTED], Peter Bunclark writes: The POSIX definition makes it impossible to correctly handle leap seconds with any complying implementation of the standard, and therefore applications which needs to be *truly* leapsecond compliant, cannot use the standard libraries. So we need just one other, published, open, correctly implemented, and tested library and all your problems go away. No, because all sorts of governments and companies mandate POSIX compliance so you couldn't sell the resulting product. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
In message [EMAIL PROTECTED], Rob Seaman writes: Yes, I assert that we already agree on what I'm saying - or trying to say here. Let's put aside six years of squabbling about details and look at the larger picture. John Cowan and others on the leap seconds suck side of the discussion have often said things that indicate that, whatever the tolerance, there is some common sense connection between darkness and the concept of midnight: as long as the clock doesn't say noon when it's midnight But apart from a select little crew of time-nuts and the geographically gifted, nobody has UTC on their clock: They have local time which is some number of minutes offset from UTC. We could replace UTC with TAI, or kill leapseconds in UTC and let it keep its offset from TAI or do a myriad of other things and still keep the clock as people see it on their wrist [1] in sufficient sync with the light of day through minor acts of timezone adjustments. If you want to get me to agree with you on something resembling the statement you made, then it is this: Local Legal/Civilian time will probably always have the sun highest in the sky somewhere around 12:00 through political modification of timezone affiliation. It follows trivially from there that it doesn't matter a dingos fetid kidneys [2] to legal/civilian time what UTC does with relation to the Sun, as long as it is not something ridiculous as monthly leapseconds. Poul-Henning [1] VCR's will probably still flash 12:00AM though. [2] Yes, I just saw the movie :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: vive le BIH!
In message [EMAIL PROTECTED], John.Cowan writes: Clive D.W. Feather scripsit: The problem here is Microsoft, whose software appears to believe that the current LCT here is GMT Daylight Time. How thoroughly stupid. Nevertheless, when I talked to the teleconference organizer, it became thoroughly clear that for him GMT meant the time on my wristwatch or wall clock, and that he had no idea that anyone had any other meaning for the abbreviation. It is not unrelated to why some of us think that changing the definition of UTC is infinitely more possible than changing the rest of the worlds educational level with regards to timekeeping. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
In message [EMAIL PROTECTED], Rob Seaman writes: Poul-Henning Kamp wrote: It is not unrelated to why some of us think that changing the definition of UTC is infinitely more possible than changing the rest of the worlds educational level with regards to timekeeping. Not unrelated, simply completely irrelevant. Your argument, apparently shared by the folks pushing the ITU proposal, is not without merit. Folks don't understand civil time issues now and we have little hope they ever will, so why not take the purely pragmatic action of redefining UTC? The failure of your argument is not that public policy in an imperfect world sometimes requires compromise. The failure is that the compromise being offered doesn't address the problem at hand. I thought you were busy with your analysis document ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Precise time over time
In message [EMAIL PROTECTED], Greg Hennessy writes: Will you support a proposal that keeps leap-second (or -minutes), but mandates that they be determined 40 or 50 years in advance ? Determined to what accuracy? Whatever the prediction is able to nail it to. I realize that this means that the bounds on |UT1-UTC| increases to about a minute, worst case, but already given todays predictive capabilities, I think it will be possible to keep the difference within a handful of seconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Precise time over time
In message [EMAIL PROTECTED], Rob Seaman writes: On Aug 11, 2005, at 12:46 AM, Poul-Henning Kamp wrote: As I understood the situation last week, nobody in the gang here had problems with leap seconds if we got a longer warning (40-50 years). So what prevents us from writing up our own proposal to ITU ? I'm pretty sure that we could get a rather impressive list of signatures from both camps if we did a bit of lobby work in our respective communities. A reasonable idea. Of course, there is no reason to suppose that any such proposal would even get a reading from the committee. If it gets put officially on their table by an ITU-R member state, their rules does not allow them to ignore it. Worst case it will take a few thousand CHF to get somebody accredited as a WP sector member in order to get it put in their inbox. The question is whether a deterministic 50 year solution exists. Not really, the question is how large excursions |UT1-UTC| would take because of imperfect prediction. Would love some feedback from the Earth rotation experts as to the current and projected state of the art for making such predictions. You are guaranteed to get that feedback if we put the proposal officially in front of WP7A. The question of this scheduling horizon is independent of the leap second scheduling algorithm itself. I consider this a feature of my proposal. Sweeping leap seconds under the rug is not going to solve the underlying problems.) There is no reason that my proposal could not be combined with the 50 year predictive horizon to satisfy both of us. Absolutely. No disagreement there, but I doubt the predictive capability will be able to gain much performance from being allowed to schedule a leapsecond on 2049-11-30 instead of 2049-12-31 at this point in time. That of course is not the same as saying that we can't in the future, so I'm open for it. As far as the maximum permitted size for DUT1 - some think 0.9 seconds is too small. There appears to be a consensus among quite divergent thinkers here that 0.9 hours is much too big. If we go to 50 years horizon, then the permitted size will have to go. The size will be whatever the predictive capability results in. I would think that we can keep it less than 5 seconds at this point, and probably better than 1 second 20 years down the road. If we put a cap on it, we have two conflicting requirements and we gain nothing but trouble. It would be trivial, however, to convert the current UTC standard based on leap seconds into a standard based on leap minutes. That is another option which might be workable, but the criteria must still be set so that the leap-minute does not get announced with 6 months notice. But I think the predictive capability would already allow us to hold it well inside a minute with a 50 second horizon and leapseconds. I would even think that there would be time to change TF460 in a structured way before we would hit the 1 minute, should something unexpected but non-catastrophic happen to Earth. - are leap minutes likely to be more palatable to Kamp's caricature of a moronic Posix programmer? What matters here is not the nature of the exceptional counting, but the fact that we can narrow the scope to operating system programmers if we have sufficient horizon. If the horizon is long enough, we can make the operating system do the right thing and then it will take a truly moronic programmer to screw it up, as opposed to now where it takes a truly dedicated programmer to get it right. I still argue that the way to encourage compliance to a standard is to make non-compliance a non-option. A project facing the prospect of dealing with a potential leap second monthly is a project that will actually expend the effort to get this right. A project facing an event 50 years - or even 10 years - in advance will simply ignore that event. I disagree. The problem with the current short horizon is that it involves the users in the event because they have to update software to get it right. If the horizon allows the knowledge to be safely put into the operating system, knowing that it will be correct for the lifetime of the system then only a few people for each operating system need to be involved and get it right. Why don't we (the larger we, including the folks with the power who haven't been participating in any discussions) simply regroup, withdraw the current silly proposal and define a process to patiently and prudently reach a consensus. Because the people behind the current proposal is driven by economics, not science. If we want to stand a chance in this fight, we have to come up with a competing propoposal with competitive economy and better science. And we have to do it in the next few months. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained
Re: Precise time over time
In message [EMAIL PROTECTED], Mark Calabretta writes: However, the question that naturally arises is the required timescale of the extrapolation. A figure of 50 years seems first to have been suggested by Poul-Henning Kamp (Aug/04, My personal opinion is that 50 years seems right, 20 years might be livable) and since seems to have become set. However, I question the need for such a long extrapolation. As I said, 50 years seems right, and it does so because there is no currently running computer that has worked for 50 years. Most electronics is considered unreliable for safety of life after 10-20 years and in general after about 30-40 years. 20 years might be livable because while there are computers which have been running for more than 20 years, having to update a table for those few systems might be livaable, but it does get us into the area where long lived embedded systems need updates. I know of far too many 15-20 year old systems still running, and the way things are, I suspect I still know a lot of them in five or ten years time, but then as 20 to 30 year old systems. I think the idea would be much more saleable with an initial timescale of, say, 20 years, extended by 5 years every 5 years. So at any time the extrapolation would range between 15 and 20 years. No, that is too short, 20-25 years _maybe_ but certainly no shorter than that. The only way we can compete economically with the existing proposal is if we can make leapseconds a non-issue for all users, operators and programmers and make them a concern for operting system programmers only. For that to work, it needs to be such that you can deply a system and not have to think about leapseconds for the lifetime of it. It doesn't work if some of the programmers, operators or users need to be aware of leapseconds and some don't, because then they all need to be aware to tell if they in one or the other crowd. It has to cover everybody until they are clearly aware that they are running an antique computer and not just a trusty old computer. In the US I belive something is antique when it is 25 years old, in Europe I think it has to be 50 years old to gain the distinction. So I think 50 years is the correct horizon. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Precise time over time
In message [EMAIL PROTECTED], Clive D.W. Feather writes: Poul-Henning Kamp said: As I said, 50 years seems right, and it does so because there is no currently running computer that has worked for 50 years. Actually, the programme machines that control the signalling of much of the London Underground are somewhat older than that. They run to, IIRC, a 15 second accuracy (I'd have to dig out various technical papers to be sure). The Copenhagen S-trains are controlled by a 30 year old system I think. In the US I belive something is antique when it is 25 years old, in Europe I think it has to be 50 years old to gain the distinction. 100 years. -- Clive D.W. Feather | Work: [EMAIL PROTECTED] | Tel:+44 20 8495 6138 Internet Expert | Home: [EMAIL PROTECTED] | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc|| -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
