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: 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.
Re: Longer leap second notice
Clive D.W. Feather scripsit: John Cowan said: Barry gules and argent of seven and six,John Cowan on a canton azure fifty molets of the second. [EMAIL PROTECTED] --blazoning the U.S. flag http://www.ccil.org/~cowan You don't get odd numbers of barry. It's Gules, six bars argent. I have received comments to this effect, but also to the opposite effect. In any case, the Great Seal of the United States is blazoned in the enabling legislation [p]aleways of thirteen pieces, argent and gules, which is certainly relevant precedent, since the even-only theory of barry is also usually applied to paly. Infinite are the arguments of mages. -- One Word to write them all, John Cowan [EMAIL PROTECTED] One Access to find them, http://www.reutershealth.com One Excel to count them all,http://www.ccil.org/~cowan And thus to Windows bind them.--Mike Champion
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: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
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. 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. -- William Thompson NASA Goddard Space Flight Center Code 612.1 Greenbelt, MD 20771 USA 301-286-2040 [EMAIL PROTECTED]
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: TAI Owned by BIPM / Metre Convention This is indisputably agreed to be true since the demise of the BIH. I know of no endorsement for the use of TAI outside of metrological circumstances. 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. 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. The branch of the IERS responsible for the UTC offset currently asserts that it is still following the UTC rules from the CCIR before there was an IERS. 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. The whole scheme works now because there is still consensus about the way in which the original agreements are to be interpreted. It remains to be seen whether the gentleman's agreements which hold this whole scheme together will tolerate a non-consensual arrangement. Now tell me why you think Leap seconds are so important again. In a word, I offer psychology. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Longer leap second notice
John Cowan said: Barry gules and argent of seven and six,John Cowan on a canton azure fifty molets of the second. [EMAIL PROTECTED] --blazoning the U.S. flag http://www.ccil.org/~cowan You don't get odd numbers of barry. It's Gules, six bars argent. -- 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||
Fwd: [LEAPSECS] Longer leap second notice
On Jan 3, 2006, at 5:46 PM, Warner Losh wrote: As someone who has fought the battles, I can tell you that a simple table is 10x or 100x easier to implement than dealing with parsing the data from N streams. Sure, it limits the lifetime of the device, but a 20 year limit is very reasonable. Simpler is indeed better - if it satisfies the requirements. While we're at it - how about a table to describe worldwide daylight saving rules? Oh right - we already have that :-) What we don't have is a mechanism to force the U.S. Congress not to change the rules out from under us. Retaining the flexibility to easily change the rules is one of our requirements. Twenty years does seem reasonable. Would suggest this might be marketed as an extended cadence maintenance requirement, rather than as an expiration date - suspect astronomers aren't the only ones to rely on 30 year old computers on occasion. I would heartily agree with the notion that a twenty year horizon is about appropriate for expecting to reach any decision on the future of UTC. We'd be a lot further ahead on this if a closed door decision hadn't been rushed for the imagined benefit of the few. In the mean time, there are many members of the astronomical software community who would be happy to contribute to an effort to improve time handling infrastructure and standards, rather than spending their own precious time fending off ill conceived political machinations. If we could have a table for the next 20 years, there'd be no need to even write the code to get from the GPS stream :-) And if latitude and longitude were engraved on every street corner, there would be no need for GPS at all :-) Transport of time signals to remote locations is the whole point. I know you aren't pursuaded by such arguements. I'm prepared to be persuaded by complete, coherent proposals based on real world (and real economic) concerns. But should any of us be open to persuasion by a political tool to make the proposal go through without commiting anybody to anything for the next couple of hundred of years? I find your dismissive attitude towards software professionals that have implemented a complete leap second handling infrastructure, with pluggable sources for leap second rather annoying :-( Indeed, I'm sure I've exhausted my scant store of good will again. It must be obvious that my intent was to come out swinging after the leap second - just as the obvious intent of the folks pushing the proposal is to use any reports of systems failing to appropriately handle the leap second as fodder for renewing their efforts. That said, if there are such reports, let's hear them and get to work together (for once). (Some might consider me a software professional as well - am not particularly annoyed if you do not.) Would be delighted to hear more about your leap second infrastructure. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : On Jan 3, 2006, at 5:46 PM, Warner Losh wrote: : : As someone who has fought the battles, I can tell you that a simple : table is 10x or 100x easier to implement than dealing with parsing : the data from N streams. Sure, it limits the lifetime of the : device, but a 20 year limit is very reasonable. : : Simpler is indeed better - if it satisfies the requirements. While : we're at it - how about a table to describe worldwide daylight saving : rules? Oh right - we already have that :-) What we don't have is a : mechanism to force the U.S. Congress not to change the rules out from : under us. Retaining the flexibility to easily change the rules is : one of our requirements. You are comparing two dissimilar things. 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. These too represent the fact that the oribit arount the earth is not exactly 365.25 days. We add leap seconds because the rotation of the earth isn't exactly 86400s. The difference between them is that the earth's rotation around the sun is more stable than its rotation on its axis. Daylight savings time is something else entirely. It is a political decision that sunlight is better used in the evening than the morning. : Twenty years does seem reasonable. Would suggest this might be : marketed as an extended cadence maintenance requirement, rather than : as an expiration date - suspect astronomers aren't the only ones to : rely on 30 year old computers on occasion. I would heartily agree : with the notion that a twenty year horizon is about appropriate for : expecting to reach any decision on the future of UTC. We'd be a lot : further ahead on this if a closed door decision hadn't been rushed : for the imagined benefit of the few. In the mean time, there are : many members of the astronomical software community who would be : happy to contribute to an effort to improve time handling : infrastructure and standards, rather than spending their own precious : time fending off ill conceived political machinations. Twenty years is an example number. Ideally, as predictive science gets better, we can do it for longer periods of time. One would hope to eventually have a schedule that's published 50 or 100 years in advance. Leap years have been published far in advanced for thousands of years now, with only one correction to the rule about 700 years ago as the measurement of the year was refined. As we've refined it further in the last few hundred years, we know, with a very high degree of confidence, that the rule is good for at least a thousand years. The rule isn't perfect, as almost a full day of error can accumulate in 400 years (requiring an extra leap day), but it does bound the error nicely. If we can extend the horizon from 6 months, then that would lead to better predictibilty of leap seconds, and also allow for better testing. Of course, a rule that eliminates them entirely would also fit these needs, but appears to have little support... : If we could have a table for the next 20 years, there'd be no need : to even write the code to get from the GPS stream :-) : : And if latitude and longitude were engraved on every street corner, : there would be no need for GPS at all :-) Transport of time signals : to remote locations is the whole point. I think it would have been better if I'd stated my point more directly: Multiple sources of information about leap seconds leads to a more robust system. GPS can tell us about it, ntpd can tell us about it, and having a table of known leap seconds can inform us. These redundant sources of information act as a sanity check. In the development box that did do the leap second correctly, a backup source of infomration allowed it to perform correctly over the leap second despite its development not being complete. : But should any of us be open to persuasion by a political tool to : make the proposal go through without commiting anybody to anything : for the next couple of hundred of years? There are a number of politically expedient quick fixes. Foisting it off on future generations is a time honored political solution :-(. : I find your dismissive attitude towards software professionals that : have implemented a complete leap second handling infrastructure, : with pluggable sources for leap second rather annoying :-( : : Indeed, I'm sure I've exhausted my scant store of good will again. My statement was born of frustration. It was a little uncalled for. I regret sending it as it was a cheap shot. : Would be delighted to hear more about your leap second infrastructure. In brief, we have a leap second table. This table can be populated from a number of different sources, usually via a table we've hard coded into our products. As the products run and discover new leap seconds, these are added to the table and the
Re: Longer leap second notice
Rob Seaman scripsit: 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) Why do you persist in claiming that all parties must certainly agree on something that is precisely the point most in dispute? No communication with you is possible until you accept that there *is* a controversy over this. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, Oxen of the Sun [EMAIL PROTECTED]
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: Longer leap second notice
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. I'm glad someone else came to this conclusion too. But be careful, though, that this line of thought isn't used to justify leap hours over leap seconds. One leap hour predicted for a fixed date of, say, the year 2600 is about one part in 5 million; still 15x better than the Gregorian calendar. /tvb
Re: Longer leap second notice
Ed Davies scripsit: The main requirements for local civil time for the bulk of its users are that: Agreed. 1. local civil time matches apparent solar time roughly (e.g., the sun is pretty high in the sky at 12:00 and it's dark at 00:00). I think the last is the important point, or more specifically that the bulk of the population not begin work on one day and end on another (astronomers excepted, of course). This would be a bookkeeping nightmare. -- Barry gules and argent of seven and six,John Cowan on a canton azure fifty molets of the second. [EMAIL PROTECTED] --blazoning the U.S. flag http://www.ccil.org/~cowan
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: Longer leap second notice, was: Where the responsibility lies
On Jan 3, 2006, at 4:22 PM, Poul-Henning Kamp wrote: 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. I'm willing to entertain any suggestion that preserves mean solar time as the basis of civil time. One could view this notion as a specific scheduling algorithm for leap seconds. My own ancient proposal (http://iraf.noao.edu/~seaman/leap) was for a tweak to the current algorithm that would minimize the excursions between UTC and UT1. This suggestion is more than a tweak, of course, since it would require increasing the 0.9s limit. One could imagine variations, however, with sliding predictive windows to balance the maximum excursion against the look ahead time. One is skeptical of any advantage to be realized over the current simple leap second policy. I continue to find the focus on general purpose computing infrastructure to be unpersuasive. If we can convince hardware and software vendors to pay enough attention to timing requirements to implement such a strategy, we can convince them to implement a more complete time handling infrastructure. This seems like the real goal - one worthy of a concerted effort. Instead of trying to escape from the entanglements of this particular system requirement, why don't we focus on satisfying it in a forthright fashion? There is also the - slight - issue that we aren't only worried about computers. There is a heck of a lot of interesting infrastructure that should be included in the decision making envelope. In general, the strategy you describe could also be addressed as an elaboration on the waveform we are attempting to model with our clocks. Not a constant cadence like tick-tick-tick-tick, that is, but tick-tick-tock-tick. I do think there might be some interesting hay to be made by generalizing our definition of a clock to include quasi-periodic phenomena more complicated than a once-per-second delta function. Would give us some reason to explore the Fourier domain if nothing else. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice, was: Where the responsibility lies
I continue to find the focus on general purpose computing infrastructure to be unpersuasive. If we can convince hardware and software vendors to pay enough attention to timing requirements to implement such a strategy, we can convince them to implement a more complete time handling infrastructure. This seems like the real goal - one worthy of a concerted effort. Instead of trying to escape from the entanglements of this particular system requirement, why don't we focus on satisfying it in a forthright fashion? As someone who has fought the battles, I can tell you that a simple table is 10x or 100x easier to implement than dealing with parsing the data from N streams. Sure, it limits the lifetime of the device, but a 20 year limit is very reasonable. I had one system that worked over the leap second correctly, even though the code to parse the data from this specific brand of GPS receiver hadn't been written yet. It worked because it knew about the leap second in a table that we'd included on our flash as a fallback when we didn't know anything else. If we could have a table for the next 20 years, there'd be no need to even write the code to get from the GPS stream :-). I know you aren't pursuaded by such arguements. I find your dismissive attitude towards software professionals that have implemented a complete leap second handling infrastructure, with pluggable sources for leap second rather annoying :-( Warner
