Re: [LEAPSECS] Meeting with Wayne Whyte
On Thu, 3 Feb 2011, Clive D.W. Feather wrote: > michael.deckers said: > > > >Very interesting, thanks! The "double leap second" resurfaced > >in the ISO standard for C in 1989. > > However, this (and its adoption by reference into Posix) was due to a > misunderstanding by the people in WG14 at the time. When I fully understood > what was going on, I got WG14 to fix the C Standard (and, again by > reference, Posix) to only allow 61 seconds per minute at most. I wondered if it dated back further, perhaps to the /usr/group standard. I don't have my copy of the BSD SCCS repository to hand, but the 4.3-Tahoe manual (dating from 1987-8 ish) still says seconds go from 0-59. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
michael.deckers said: >> However, this suggestion of increasing the limit of DUT1 should >> go hand in hand with another change made in Rec. 460. The original >> draft of 460 which was presented to the CCIR Plenary Assembly >> suggested that the leaps should be full seconds or "integral >> multiples thereof". > >Very interesting, thanks! The "double leap second" resurfaced >in the ISO standard for C in 1989. However, this (and its adoption by reference into Posix) was due to a misunderstanding by the people in WG14 at the time. When I fully understood what was going on, I got WG14 to fix the C Standard (and, again by reference, Posix) to only allow 61 seconds per minute at most. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2011-02-03 08:58, michael.deckers penned without tinking: They probably realized that |TAI - UTC| < 1 s excludes multiple leap seconds. when he meant |UT1 - UTC| < 1 s. Sorry for the confusion. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2011-02-03 08:04, Steve Allen wrote: However, this suggestion of increasing the limit of DUT1 should go hand in hand with another change made in Rec. 460. The original draft of 460 which was presented to the CCIR Plenary Assembly suggested that the leaps should be full seconds or "integral multiples thereof". Very interesting, thanks! The "double leap second" resurfaced in the ISO standard for C in 1989. Somehow during the discussions at the Plenary Assembly the phrase in quotes was deleted before adoption of the draft recommendation. They probably realized that |TAI - UTC| < 1 s excludes multiple leap seconds. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2011 Feb 2, at 23:44, Tom Van Baak wrote: > Over the past 4 decades the recommended tolerance for > DUT1 has gone from 0.1 s to 0.5 to 0.7 to 0.9 seconds. The 0.7 was in the original 1970 version of Rec. 460 which was supposed to let DUT1 fit in 3 bits of BCD clicks. The response from the BIH must have been something like "The earth is spinning slower now than it has since 1912 and we have to compute this stuff by hand using input data that's delivered to us by boats so we can't give you better than 0.9 s", and that's what was written into the first revision of Rec. 460. Fortunately for everyone the earth's crust speeded up starting right then, so 1972 was the only year with two leap seconds. However, this suggestion of increasing the limit of DUT1 should go hand in hand with another change made in Rec. 460. The original draft of 460 which was presented to the CCIR Plenary Assembly suggested that the leaps should be full seconds or "integral multiples thereof". Somehow during the discussions at the Plenary Assembly the phrase in quotes was deleted before adoption of the draft recommendation. (I hope that the delegates to the Radiocommunications Assembly which votes on the current draft revision of TF.460 feel equally empowered to change the wording.) Anyway, if the limit on DUT1 is increased thus then it might make sense to re-instate the mythical POSIX "double leap second". -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
[ I'm posting this unsent email now that Warner independently proposed the same thing! ] In that is the nugget of how leap seconds are no different announcements that the daylight/summer time zones transition will happen at some date other than the previous schedule. (e.g., due to some sports event like the 2000 Olypmics and the 2006 Commonwealth Games in Australia, or any of the other excuses that bureaucrats have used when they say you'll have to update your zoneinfo files.) Even if this were true, I think we can give them a break for Y2K and expect it not to happen too many more times. So here's an idea to test the waters slowly -- To see which or if any applications run into trouble when DUT1 exceeds 0.9 second -- how about if IERS stretches it very slowly... Over the past 4 decades the recommended tolerance for DUT1 has gone from 0.1 s to 0.5 to 0.7 to 0.9 seconds. Why not continue this trend over the next decade or two? Delay the next leap second by 6 or 12 months and push just over the 1.0 edge and see if the water is too hot for some piece of gear. If so, it can probably be fixed. And given how much DUT1 varies day by day, the failure will not be a hard failure; it will be intermittent. Plenty of time to fix it before the next leap second brings DUT1 back under 1.0. Leap seconds would still occur, but this would provide an orderly slow triage of equipment or software that needs attention. Instead of the emotional, political, and technical uncertainty of removing leap seconds altogether, just aim for the very simple goal of |DUT1| < 2.0 seconds. A small step instead of a giant leap... /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Agreed. And I believe that the terms TU0, TU1, and TU2 and the corresponding UT0, UT1, and UT2, predated the introduction of UTC and so it was "natural" to extend the series to TUC and UTC for Coordinated Universal Time. -- Richard Quoting Steve Allen : On Tue 2011-02-01T16:53:24 -0700, Rob Seaman hath writ: What would that be in French? Probably "Temps something something", right? The acronym would presumably have to avoid both UTC for the English and Txx for the French. Maybe CUT as described at: http://www.nist.gov/pml/div688/utcnist.cfm#cut Alas for NIST, this web snippet is not consistent with the written record in the proceedings of the CCIR 1970 Plenary Assembly. In the adopted recommendation on page 227 of volume 3 (which is in French) the only time scale repeatedly mentioned is "temps universel (TU)". In the description of the events leading to the new recommendation on page 182 of volume 7 (which is in English) the text reads "improvement of the U.T.C. (Universal Coordinated Time) system" but the summary of the content of the new recommendation repeatedly and only mentions "Universal Time (U.T.)" I deem the NIST explanation to be ex post facto and ad hoc. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs === Richard B. LangleyE-mail: l...@unb.ca Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ === ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 02/01/2011 16:53, Rob Seaman wrote: Poul-Henning Kamp wrote: They might just call the new leap-less timescale "Unified Time for Communication" What would that be in French? Probably "Temps something something", right? The acronym would presumably have to avoid both UTC for the English and Txx for the French. Maybe CUT as described at: http://www.nist.gov/pml/div688/utcnist.cfm#cut Works for me. Let's hope then they don't call it New Unified Time for Coordination, since the French acronym might be unfortunate in English... w Warner Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 1 Feb 2011 at 13:23, Steve Allen wrote: > This is the problem which corporations solve by trademarks which allow > them ownership of words and ability to protect and change their > meaning. Unless the trademark falls victim to "genericide", where enough people use it as a generic word that a court eventually decides that it is no longer protected. That's why Google prefers people not refer to "googling" for something, as flattering as that is to their company. Other trademarks in some degree of danger of this sort, some of which have proceeded so far in the direction of genericness that you might not even realize they're trademarks, include Kleenex, Xerox, Ping-Pong, Rollerblade, and Realtor. Former trademarks that went generic include aspirin, cellophane, zipper, and escalator. > Today anyone who goes around calling people "gay" is going to be > regarded as ignorant or offensive. Do it at a gay pride parade and they'll probably say "Well, duh!" -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue 2011-02-01T16:53:24 -0700, Rob Seaman hath writ: > What would that be in French? Probably "Temps something something", right? > The acronym would presumably have to avoid both UTC for the English and Txx > for the French. Maybe CUT as described at: > > http://www.nist.gov/pml/div688/utcnist.cfm#cut Alas for NIST, this web snippet is not consistent with the written record in the proceedings of the CCIR 1970 Plenary Assembly. In the adopted recommendation on page 227 of volume 3 (which is in French) the only time scale repeatedly mentioned is "temps universel (TU)". In the description of the events leading to the new recommendation on page 182 of volume 7 (which is in English) the text reads "improvement of the U.T.C. (Universal Coordinated Time) system" but the summary of the content of the new recommendation repeatedly and only mentions "Universal Time (U.T.)" I deem the NIST explanation to be ex post facto and ad hoc. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue 2011/02/01 11:49:02 -, Tony Finch wrote in a message to: Leap Second Discussion List >However the Gregorian calendar can be implemented in a few static lines of >code, which is orders of magnitude less than is required to handle dynamic >updates of the leap second table. The two are in no way comparable. It goes back to the fundamental problem of unpredictability. If I could give you a list of leap seconds for the next millenium, then most of your orders of magnitude more code, mostly presumably dealing with the updates, would melt away. In any case, as we used to say, this is just an implementation detail. Someone does it, and everyone else uses it. Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue 2011/02/01 10:59:26 -, Stephen Colebourne wrote in a message to: Leap Second Discussion List >> The fundamental problem is that there is no formula for determining >> when leap seconds occur. > >No, the rules for inserting leap seconds are simple enough in >computation terms. The problem is entirely with the 23:59:60 notation >being unacceptable to the API design. Without wishing to downplay the problems you are having with the Java API, the 23:59:60 notation cannot be said to be a fundamental problem with UTC itself in the sense I intended. After all, you have designed the API for classes that do handle UTC properly. In the same vein, representing UTC in Julian Date form is a problem, but not fundamental in any sense. The API of the SOFA library shows one way of handling it - http://www.iausofa.org/ . Representing the 61st second on an analogue clock face is another problem, again not fundamental - solutions can be found. Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue 2011/02/01 10:09:35 -, "Poul-Henning Kamp" wrote in a message to: Leap Second Discussion List >And in extension of the previous discussion about words, I think >this provides us with the correct word to describe the deficiency >of the UTC timescale: "unpredictable". > >And anyone who cannot see a pythonesque dialogue in this needs a >humour-transplantation: Would you care to speculate on what the Pythons might have made of the long-term unpredictability of the Gregorian calendar itself? Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Poul-Henning Kamp wrote: > They might just call the new leap-less timescale > >"Unified Time for Communication" What would that be in French? Probably "Temps something something", right? The acronym would presumably have to avoid both UTC for the English and Txx for the French. Maybe CUT as described at: http://www.nist.gov/pml/div688/utcnist.cfm#cut Works for me. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
> They might just call the new leap-less timescale > >"Unified Time for Communication" > > To shut up one particular loud astronomers claims of propertyrights > and TLAs. If indeed leap seconds are abolished by the ITU, I am very much in favor of a name change for the time scale. The name change serves as an alert to those who made engineering decisions based on the definition (with no explicit expiration date) of the timescale and its promise to remain within 0.9s of UT1. Choosing a new name that happens to have the same TLA would not be my preference, but changing the name to something that happens to have the same TLA is preferable to no name change at all. Idle Question: If they were to replace Coordinated Universal Time with Unified Time for Communication, would those jurisdictions which adopted Coordinated Universal Time for legal civil time automatically switch to Unified Time for Communication because the TLA happens to be the same? I would think not. If the ITU starts promulgating standards for Unified Time for Communication, perhaps some other body could take up the continued maintenance (with leap seconds) of Coordinated Universal Time. If the ITU just simply abolishes leap seconds, and continue to call Coordinated UT without leap seconds Coordinated Universal Time, then they will have lost some credibility as a standards setting organization. If this happens, I fully expect some folk will decide that it is easier to continue to run their systems on some close approximation of UT, and we will see some NTP servers continue ticking some approximation to UT (perhaps very much like what UTC is today) while others go off on a new time scale which is some fixed offset from TAI. Unfortunately, the NTP protocol has no good way of carrying any indication of which time scale it is carrying, so at the boundaries (where an NTP server from one camp is communicating with an NTP server in the other camp) there will be some unfortunate SNAFUs. I believe NTP does have a way for stratum 1 NTP servers to indicate how they are getting time, at least through administrative protocol interfaces if not the protocol itself, but that doesn't get passed along through the stratums, and certainly was not contemplated as a way of distinguishing different time scales when the protocol was designed. Proposing a rev of the NTP protocol to add this information would not obviously help, because the rationale for continuing to run some NTP servers and clients on a good approximation to UT will be precisely because it is easier to do that than to try and update software (firmware?) inside those systems. If you could update to a new revision of the NTP protocol, then you could presumably update the system to no longer depend on the difference between UTC and UT1 being bounded. -Tim Shepard s...@alum.mit.edu ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue 2011-02-01T20:46:49 +, Poul-Henning Kamp hath writ: > Words have only the meanings we give them Rob, and only as far > as we give them that meaning. > > My grandmothers brother was decribed as a "A Very Gay Character" > when he arrived in New Orleans many years ago. Today he wouldn't be, > because we give a new meaning to that word. > > "Universal" had one meaning in the late 18-hundreds, but today > our universe is a lot bigger, what with space probes leaving > the solar system and all, so maybe it is time to make our > timescale "universal" rather than "universe as seen from this > planet". This is the problem which corporations solve by trademarks which allow them ownership of words and ability to protect and change their meaning. That sword cuts both ways. For example, the accounting firm Andersen Consulting got tangled up with Enron and decided it was better to be known as Accenture. Even in the presence of a trademark it is not possible to assert complete control over the common usage of a name. This is what happened to GMT in 1925 when the Admiralty decided to change the tabulations in the Nautical Almanac so that the GMT day started at Midnight instead of Noon, the way it had been for well over a century. The IAU had requested that the Admiralty not do this. After they did no power could guarantee that people would know about the change, and no power could guarantee that those who knew would use it consistently, and no power could guarantee correct interpretation of the meaning of a precision timestamp expressed as GMT after that change. Therefore the IAU abandoned the term GMT and named UT as the unambiguous way to assert a precision time stamp. If the characteristics of the broadcast time scale change but the name stays UTC then any existing document which specifies UTC will become ambiguous, requiring judgement by somebody, or even a court of law, to interpret the original intent of the document. So if the meaning of a word changes, it's best simply not to depend on it. Today anyone who goes around calling people "gay" is going to be regarded as ignorant or offensive. Is this the sort of result that the ITU-R wants? -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Feb 1, 2011, at 1:58 PM, Tony Finch wrote: > Actually you don't know if the politicians are going to muck around with your > timezone offset, so your certainty isn't all that great. Precisely. So let's avoid maximizing the uncertainty for future historians, lawyers and etc who have to sort out what happened when. It would be nonsensical to encourage a kaleidoscopically shifting pinwheel of timezones that will pollute all future interpretations of civil date and timestamps. ...and need it be mentioned yet again that none of this is in the ITU draft? There is no planning whatsoever for how the embargoed leap seconds will be later accommodated. The actual proposal on the table is devoid of due diligence. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue, 1 Feb 2011, Michael Deckers wrote: > >As far as the civil uses of time scales are concerned, it is actually >UTC rather than TAI that is currently more "predictable": I can >predict with great certainty that I shall attend a group meeting >when UTC will be 2012-01-30 + 09 h, but TAI at that instant is >currently only known with an uncertainty of 1 s. Actually you don't know if the politicians are going to muck around with your timezone offset, so your certainty isn't all that great. However you will almost certainly attend the meeting at 2012-01-30 10:00 local time (if I have guessed your location correctly). http://fanf.livejournal.com/104586.html Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2/1/2011 3:24 PM, Michael Deckers wrote, in part: On 2011-02-01 11:35, Poul-Henning Kamp wrote: How could the unpredictable difference TAI - UTC be a problem if everybody (including every computer) just kept UTC? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs Not every computer has access to UTC. I grant you, the ones that don't probably can't keep time of day at all but one must still be careful about the word "every". Gerry Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message <16501ada-631b-4fbb-b93b-2838f3891...@noao.edu>, Rob Seaman writes: >On Feb 1, 2011, at 12:05 PM, Poul-Henning Kamp wrote: > >> Note that I said "that's merely an artifact of how it is defined.", >> not "The name 'Universal Time' has an unchangeable magic meaning." > >And I suppose "Greenwich Mean Time" is completely fair game, too. Absolutely. So far they've already moved which bit of Greenwich it refers to by a couple hundred meters or when they adopted WGS84. If Charles takes that fancy, he can rename Greenwich to "Camillaville" once his mother is gone. Would that change the name of GMT to CMT ? > And "Temps Atomique International" might designate a timescale > created from an ensemble of clepsydra. There's certainly atoms in all the clepsyhdra I have seen. Words have only the meanings we give them Rob, and only as far as we give them that meaning. My grandmothers brother was decribed as a "A Very Gay Character" when he arrived in New Orleans many years ago. Today he wouldn't be, because we give a new meaning to that word. "Universal" had one meaning in the late 18-hundreds, but today our universe is a lot bigger, what with space probes leaving the solar system and all, so maybe it is time to make our timescale "universal" rather than "universe as seen from this planet". >Universal Time is a concept predating the ITU whippersnappers. >(Re)define some other timescale... I don't need to point out, that nobody wants to mess with Universal Time (UT), you can keep that for all we care. And be careful what you ask for. They might just call the new leap-less timescale "Unified Time for Communication" To shut up one particular loud astronomers claims of propertyrights and TLAs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2011-02-01 11:35, Poul-Henning Kamp wrote: Thanks to leap-seconds we do not know how long (certain) minutes are, until Daniel tells us. Daniel Gambis does not define certain time units, he just communicates the difference TAI - UTC as soon as it becomes known for another six months. "UTC is unpredictable" is the core of the problem, and a problem that must be solved, either by extending the predictability horizon from six months to at least 10 years, or by making UTC predictable. What currently is unpredictable far into the future is the difference TAI - UTC. Now the difference TAI - TT is also unpredictable -- but is that a reason to say that either TAI or TT is unpredictable, or to redefine one of them? As far as the civil uses of time scales are concerned, it is actually UTC rather than TAI that is currently more "predictable": I can predict with great certainty that I shall attend a group meeting when UTC will be 2012-01-30 + 09 h, but TAI at that instant is currently only known with an uncertainty of 1 s. How could the unpredictable difference TAI - UTC be a problem if everybody (including every computer) just kept UTC? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Feb 1, 2011, at 12:05 PM, Poul-Henning Kamp wrote: > Note that I said "that's merely an artifact of how it is defined.", > not "The name 'Universal Time' has an unchangeable magic meaning." And I suppose "Greenwich Mean Time" is completely fair game, too. And "Temps Atomique International" might designate a timescale created from an ensemble of clepsydra. And "GPS" could provide spatial and temporal coordinates derived from a System of Guinea Pigs. Universal Time is a concept predating the ITU whippersnappers. (Re)define some other timescale... ...especially since the whole idea appears to be to use UTC as a Nelson's Bridge to ultimately deprecate TAI. For precision timekeepers they appear to have remarkably little respect for the precise meaning of time. Rob Seaman National Optical Astronomy Observatory ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message <63b1a158-8efc-4309-a04d-e147e2025...@noao.edu>, Rob Seaman writes: >On Feb 1, 2011, at 11:09 AM, Poul-Henning Kamp wrote: > >>> But Universal Time is *inherently* unpredictable. (That's its charm :-) >> >> No, that's merely an artifact of how it is defined. > >Note I said "Universal Time" not "UTC". Note that I said "that's merely an artifact of how it is defined.", not "The name 'Universal Time' has an unchangeable magic meaning." -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Feb 1, 2011, at 11:09 AM, Poul-Henning Kamp wrote: >> But Universal Time is *inherently* unpredictable. (That's its charm :-) > > No, that's merely an artifact of how it is defined. Note I said "Universal Time" not "UTC". If you haven't picked up on the subtle vibe, the astronomers here are perhaps most bent out of shape over the notion of redefining the thing called "Coordinated Universal Time" to no longer be a kind of Universal Time. >> - Nobody at the ITU appears to have considered such an option. > > ... And nobody who cared for that option, seems to have bothered doing the > ground work either. By all means get to work! It would be easier to recruit folks to work on such a project if the ITU's sword of Damocles weren't hanging over our heads. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message <28f22009-2391-426c-8dc8-8de953708...@noao.edu>, Rob Seaman writes: >On Feb 1, 2011, at 4:35 AM, Poul-Henning Kamp wrote: > >> "UTC is unpredictable" is the core of the problem, and a problem >> that must be solved, either by extending the predictability horizon >> from six months to at least 10 years, or by making UTC predictable. > >But Universal Time is *inherently* unpredictable. (That's its charm :-) No, that's merely an artifact of how it is defined. > - Nobody at the ITU appears to have considered such an option. ... And nobody who cared for that option, seems to have bothered doing the ground work either. Too bad... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 02/01/2011 03:59, Stephen Colebourne wrote: On 1 February 2011 05:12, Mark Calabretta wrote: It is also a central problem of time_t: how do you map this non-uniform-radix notation onto a uniform count that must always satisfy properties that explicitly mandate a uniform-radix. Vide the mapping of calendar date to Julian Date. The fundamental problem is that there is no formula for determining when leap seconds occur. No, the rules for inserting leap seconds are simple enough in computation terms. The problem is entirely with the 23:59:60 notation being unacceptable to the API design. That is *ALSO* a problem. But if you have to deploy a system that counts time correctly for the next 10 years, not knowing for sure when the leap seconds will be presents a number of challenges. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Feb 1, 2011, at 4:35 AM, Poul-Henning Kamp wrote:
> "UTC is unpredictable" is the core of the problem, and a problem
> that must be solved, either by extending the predictability horizon
> from six months to at least 10 years, or by making UTC predictable.
But Universal Time is *inherently* unpredictable. (That's its charm :-)
- Nobody here has objected to your first idea of lengthening the
"predictability horizon". We can proceed to do this with no action whatsoever
required by the ITU. This option is also compatible with all other
possibilities for long term evolution of civil timekeeping.
- Nobody at the ITU appears to have considered such an option.
The real alternative to this obvious suggestion (it must be obvious if we both
support it :-) of improving the system we have, is to design a new parallel
system ("TI" as specified in Torino in 2003) from scratch. Then current
systems can be gracefully end-of-lifed without artificial deadlines and new
systems won't have to deal with cranky old idiosyncrasies (or cranky old
temporal kibitzers :-)
Rob
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 01/31/2011 22:12, Mark Calabretta wrote: On Mon 2011/01/31 17:10:45 PDT, Warner Losh wrote in a message to: leapsecs@leapsecond.com Earlier threads have called this the 'non-uniform-radix' problem. It has been argued that there are no discontinuities in UTC, with the 59:60 notation offered as proof. However, this moves UTC from a uniform radix that everybody is used to dealing with with to one with a non-uniform-radix. We all deal every day with a non-uniform and variable radix counting system - "30 days hath September, ...". Leap seconds differ from leap days only in their unpredictability. For dates in the past few hundred years (since the adoption of the Gregorian calendar), you can 100% completely mechanically deduce the right answer without the need for tables. You cannot do that for leap seconds. If they were regularly scheduled, then that would be one thing, but they are this random, drive-by event that you get 6 months notice for. This table-driven non-uniformity might or might not technically be a discontinuity, but certainly is a pain in the back side. This is like saying that the Gregorian calendar might or might not technically be discontinuous. In truth it simply isn't discontinuous, there is no discontinuity on Feb/29 or any other day. As defined by TF.460, UTC is continuous, like the Gregorian calendar. That's all there is to it. It is also a central problem of time_t: how do you map this non-uniform-radix notation onto a uniform count that must always satisfy properties that explicitly mandate a uniform-radix. Vide the mapping of calendar date to Julian Date. True. However, this problem is also very mechanical and easy to do, unless you also factor in which years which countries used what calendar. The fundamental problem is that there is no formula for determining when leap seconds occur. Yes. And there cannot be such a formula. Unlike the period of the orbit of earth, the rotation of earth is continually changing at a rate that's unpredictable more than a few years out (apart from a general trend, the slope of which scientists don't agree on (mostly because different time periods have different slopes). Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message <9ba2c836-5910-4503-9454-2901e834b...@noao.edu>, Rob Seaman writes: >In the Python oeuvre, surely Brazil's "Central Services" is the >most apt depiction of the International Telecommunications Union: Actually, I think the dingy punchline is more appropriate: I abhor the implication that the astronomers have a leap-second problem. It is well known that we now have the problem relatively under control, and that it is the computer-nerds who now suffer in this area. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Stephen Colebourne wrote: > SI seconds are significant, but far less important than days. Yes, I love it when someone states the main point so concisely! That is exactly my main point as well, and I am delighted to know that there are now at least TWO of us on the planet who share this view! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Gerard Ashton wrote:
> It may not have been your intention, but from now on I will hear whatever you
> type in a particular accent.
>
> Poul-Henning Kamp wrote:
>>
>
>> And anyone who cannot see a pythonesque dialogue in this needs a
>> humour-transplantation:
In the Python oeuvre, surely Brazil's "Central Services" is the most apt
depiction of the International Telecommunications Union:
"Bloody typical, they've gone back to metric without telling us."
("Time Bandits" is too easy...)
Hello, Mrs Entity!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Jan 31, 2011, at 11:59 AM, Finkleman, Dave wrote: BTW, the Moslem day begins at observable moon rise, which is different than sunset. Orthodox observers in several religions (Judiasm, Islam, and others) are very concerned about precise definitions of these events and timing of prayer intervals. This is not an argument for leap seconds, it's an argument against time zones. But you know what? In most parts of the world, orthodox observers make do just fine with time zones. The proper authorities produce tables of sunset, moon rise, etc., as a function of location and its local time zone. Leap seconds are irrelevant since these celestial events are resolved to the nearest minute, not the nearest second. - Jonathan ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
It may not have been your intention, but from now on I will hear whatever you type in a particular accent. Gerry Ashton On 2/1/2011 5:09 AM, Poul-Henning Kamp wrote: In message, Mark Calabretta writes: OK Tom, I'm prepared to accept those odds. I'll give you $16 if you correctly predict the date of the next leap second, and you give me $850 if I predict the date of the next leap day. And in extension of the previous discussion about words, I think this provides us with the correct word to describe the deficiency of the UTC timescale: "unpredictable". And anyone who cannot see a pythonesque dialogue in this needs a humour-transplantation: A: Well, you see, we have this timescale called UTC, so that we all can agree what time it is. B: Brilliant! That sounds like a jolly good idea, what with all the ships and planes and whats not. A: Yes, but there's a snag you see. Due to an embarrasing little misunderstanding in the past, we cannot tell how long time there is to one year from now. B: Say again ? A: Ehh, we sort of don't know how long a year is... B: Uhm, I mean, February has 28 days (counts on fingers) yes, 28 days, March has 31 days and so on, couldn't you just add them up ? A: Ohh yes, no worries there, February and March are no problem and May is fine too, as is July to November, but June and December are a bit of a problem for us. B: (flips to the middle of his desk calendar, counts pages) Just wanted to make sure, but it seems to me that that June is 30 days, and as I recall so was it last year, right ? In fact, I don't remember any year where june wasn't 30 days and I am pretty sure that good old Ms. Wormwood taught me that this would generally be the case ? A: Yes, absolutely, 30 days, no doubt about that. ... It's more a sort of "how long are the days in June" or to be more precise, "how long is the last day in June" ? B: Ohh, I see! The God Ol' Bards troubling you isn't he ? "Shall I compare the to a summers day" and all that ? And so on... ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Tue, 1 Feb 2011, Mark Calabretta wrote:
>
> We all deal every day with a non-uniform and variable radix counting
> system - "30 days hath September, ...".
However the Gregorian calendar can be implemented in a few static lines of
code, which is orders of magnitude less than is required to handle dynamic
updates of the leap second table. The two are in no way comparable.
int greg2rd(int y, int m, int d) {
if (m > 2) m += 1; else m += 13, y -= 1;
return y*1461/4 - y/100 + y/400 + m*153/5 + d - 428;
}
void rg2greg(int d, int *py, int *pm, int *pd) {
int y, m;
d += 305;
y = d*400/146097 + 1;
y -= y*1461/4 - y/100 + y/400 > d;
d -= y*1461/4 - y/100 + y/400 - 31;
m = d*17/520;
d -= m*520/17;
if (m < 11) m += 2;
else m -= 10, y += 1;
*py = y, *pm = m, *pd = d;
}
Tony.
--
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message , Step hen Colebourne writes: >Poul, this is not true for JSR-310. A year is 365-366 days long. A day >is a fundamental unit. Thus we know exactly how long each are. I'm not talking about JSR-310, I'm talking reality. Thanks to leap-seconds we do not know how long (certain) minutes are, until Daniel tells us. By extension it follows that we do not know how long the hours, days, years, decades, centuries & millenia which ocntains one of these minutes are. "UTC is unpredictable" is the core of the problem, and a problem that must be solved, either by extending the predictability horizon from six months to at least 10 years, or by making UTC predictable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 1 February 2011 10:09, Poul-Henning Kamp wrote: > A: Ehh, we sort of don't know how long a year is... Poul, this is not true for JSR-310. A year is 365-366 days long. A day is a fundamental unit. Thus we know exactly how long each are. Taking a "second is the most important" viewpoint of the world isn't very helpful. Most of don't measure the length of a holiday in seconds, we use days or weeks. SI seconds are significant, but far less important than days. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 1 February 2011 05:12, Mark Calabretta wrote: >>It is also a central problem of time_t: how do you map this >>non-uniform-radix notation onto a uniform count that must always satisfy >>properties that explicitly mandate a uniform-radix. > > Vide the mapping of calendar date to Julian Date. > > The fundamental problem is that there is no formula for determining > when leap seconds occur. No, the rules for inserting leap seconds are simple enough in computation terms. The problem is entirely with the 23:59:60 notation being unacceptable to the API design. API users call getSecondOfMinute() and require a value 0-59. That UTC doesn't do that is a unfortunate reality, but can be handled by smoothing, provided a 2nd API is available (not the main one) that allows a determination of the 0-60 value, eg. getSecondOfMinuteWithPossibleLeapSecond() - JSR-310 effectively puts that on a separate class - UTCInstant, expressing it as getNanoOfDay() which may reach the equivalent of the 61st second. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message , Mark Calabretta writes: >OK Tom, I'm prepared to accept those odds. I'll give you $16 >if you correctly predict the date of the next leap second, and >you give me $850 if I predict the date of the next leap day. And in extension of the previous discussion about words, I think this provides us with the correct word to describe the deficiency of the UTC timescale: "unpredictable". And anyone who cannot see a pythonesque dialogue in this needs a humour-transplantation: A: Well, you see, we have this timescale called UTC, so that we all can agree what time it is. B: Brilliant! That sounds like a jolly good idea, what with all the ships and planes and whats not. A: Yes, but there's a snag you see. Due to an embarrasing little misunderstanding in the past, we cannot tell how long time there is to one year from now. B: Say again ? A: Ehh, we sort of don't know how long a year is... B: Uhm, I mean, February has 28 days (counts on fingers) yes, 28 days, March has 31 days and so on, couldn't you just add them up ? A: Ohh yes, no worries there, February and March are no problem and May is fine too, as is July to November, but June and December are a bit of a problem for us. B: (flips to the middle of his desk calendar, counts pages) Just wanted to make sure, but it seems to me that that June is 30 days, and as I recall so was it last year, right ? In fact, I don't remember any year where june wasn't 30 days and I am pretty sure that good old Ms. Wormwood taught me that this would generally be the case ? A: Yes, absolutely, 30 days, no doubt about that. ... It's more a sort of "how long are the days in June" or to be more precise, "how long is the last day in June" ? B: Ohh, I see! The God Ol' Bards troubling you isn't he ? "Shall I compare the to a summers day" and all that ? And so on... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon 2011/01/31 22:13:59 -0800, "Tom Van Baak" wrote in a message to: "Leap Second Discussion List" >True. You'll notice the continuous/discontinuous subject comes >up everytime someone new joins the list. Those words try to Unfortunately, UTC is still routinely described as "discontinuous" by people who should know better. >quite say perfectly with a single english word. Let us know if you >have a favorite alternative adjective. It's all down to predictability in the sense that I hope I made clear in my previous email, i.e. not a question of stability. Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon 2011/01/31 22:11:36 -0800, "Tom Van Baak" wrote in a message to: "Leap Second Discussion List" >The leap day error is, what, 365.2425 : 365.24219 = 850 ppb; >while a leap second every two years is 16 ppb? OK Tom, I'm prepared to accept those odds. I'll give you $16 if you correctly predict the date of the next leap second, and you give me $850 if I predict the date of the next leap day. Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
The fundamental problem is that there is no formula for determining when leap seconds occur. True. You'll notice the continuous/discontinuous subject comes up everytime someone new joins the list. Those words try to convey an easy concept that all of us know well but no one can quite say perfectly with a single english word. Let us know if you have a favorite alternative adjective. Meanwhile any use of the word continuous is like shark bait around here. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Leap seconds differ from leap days only in their unpredictability. Careful. Actually, you can go a lot more seconds of predictable leap seconds than you can go days with predictable leap years using the current 4/100/400 leap day rule. The leap day error is, what, 365.2425 : 365.24219 = 850 ppb; while a leap second every two years is 16 ppb? But I know what you mean. If you compare with the typical human lifetime, then yes, it is leap seconds that are more unpredictable for sure. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon 2011/01/31 17:10:45 PDT, Warner Losh wrote in a message to: leapsecs@leapsecond.com >Earlier threads have called this the 'non-uniform-radix' problem. It >has been argued that there are no discontinuities in UTC, with the 59:60 >notation offered as proof. However, this moves UTC from a uniform radix >that everybody is used to dealing with with to one with a >non-uniform-radix. We all deal every day with a non-uniform and variable radix counting system - "30 days hath September, ...". Leap seconds differ from leap days only in their unpredictability. >This table-driven non-uniformity might or might not >technically be a discontinuity, but certainly is a pain in the back side. This is like saying that the Gregorian calendar might or might not technically be discontinuous. In truth it simply isn't discontinuous, there is no discontinuity on Feb/29 or any other day. As defined by TF.460, UTC is continuous, like the Gregorian calendar. That's all there is to it. >It is also a central problem of time_t: how do you map this >non-uniform-radix notation onto a uniform count that must always satisfy >properties that explicitly mandate a uniform-radix. Vide the mapping of calendar date to Julian Date. The fundamental problem is that there is no formula for determining when leap seconds occur. Regards, Mark Calabretta ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 01/31/2011 15:55, Stephen Colebourne wrote: By comparison, leap seconds add a new time representation 23:59:60 which exists in no other way. Its the creation of the new time that is problematic. Earlier threads have called this the 'non-uniform-radix' problem. It has been argued that there are no discontinuities in UTC, with the 59:60 notation offered as proof. However, this moves UTC from a uniform radix that everybody is used to dealing with with to one with a non-uniform-radix. This table-driven non-uniformity might or might not technically be a discontinuity, but certainly is a pain in the back side. It is also a central problem of time_t: how do you map this non-uniform-radix notation onto a uniform count that must always satisfy properties that explicitly mandate a uniform-radix. The timezone code in Unix does deal with this by increasing the UTC-TAI offset so you could, in theory, tell the same way to tell with DST transitions. I tend to agree with you thought that it might be pounding screws with a hammer Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 31 January 2011 19:57, Steve Allen wrote: > In that is the nugget of how leap seconds are no different > announcements that the daylight/summer time zones transition will > happen at some date other than the previous schedule. > (e.g., due to some sports event like the 2000 Olypmics and the 2006 > Commonwealth Games in Australia, or any of the other excuses that > bureaucrats have used when they say you'll have to update your > zoneinfo files.) > > Leap seconds are just conventional adjustments (to an underlying > presumed-adequately-uniform time scale) which are decreed by human > authorities to be implemented at times which are deemed most > convenient. They are entirely compatible with the POSIX rules as > implemented by the zoneinfo scheme. I disagree, based on experience of implementing both time zones and leap seconds. Time zones are about the gaps and overlaps in the local timeline relative to the standard timeline. Times are repeated during an overlap, but no fundamentally new time representations are created. Jumping from 01:00 to 02:00, or overlapping from 02:00 back to 01:00, the second still runs from 0 to 59 inclusive. By comparison, leap seconds add a new time representation 23::59:60 which exists in no other way. Its the creation of the new time that is problematic. Suggesting that zoneinfo could be used to manage an overlap of the last second (23:59:59 repeats) doesn't work either, because there is no way to determine whether it is the first or second time around using the offset. With time zones, the difference between the first and second times can be determined due to the different offsets. (Time zones are correctly modelled as rules for when the offset changes, leap seconds don't change the offset so cannot use the time zone model) Basically, the software design needed to manage zoneinfo and time zones is entirely different to that needed to solve the leap second case. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Jan 31, 2011, at 12:40 PM, Warner Losh wrote: > However, given the tolerance of DUT1 is .9 and not .5, I'm sure that an extra > last leap second could be tossed in to give vendors more time to cope... Since this whole discussion has been about "predictability", it would be prudent (whatever side of the issue one is on) to include such an "extra last leap second" in the language of the draft. Something like: "This change will occur no sooner than N years after adoption of this resolution. After N years have elapsed, current procedures will be followed to schedule one final leap second in the timescale broadcast via ITU compliant facilities." Note that this would apply to implementing the Torino TI timescale as well. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon 2011-01-31T12:40:27 -0700, Warner Losh hath writ: > However, given the tolerance of DUT1 is .9 and not .5, I'm sure that an > extra last leap second could be tossed in to give vendors more time to > cope... In that is the nugget of how leap seconds are no different announcements that the daylight/summer time zones transition will happen at some date other than the previous schedule. (e.g., due to some sports event like the 2000 Olypmics and the 2006 Commonwealth Games in Australia, or any of the other excuses that bureaucrats have used when they say you'll have to update your zoneinfo files.) Leap seconds are just conventional adjustments (to an underlying presumed-adequately-uniform time scale) which are decreed by human authorities to be implemented at times which are deemed most convenient. They are entirely compatible with the POSIX rules as implemented by the zoneinfo scheme. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 01/31/2011 12:07, Rob Seaman wrote: This latency, however, is as likely to be negative as positive. With knowledge that the standard was due to change, it might well be the case that an earlier leap second during that 5 year window would be embargoed. Leap seconds have historically been scheduled as soon as possible: http://iraf.noao.edu/~seaman/leap (See the plot under "leap second scheduling.) There is no reason to believe that there will be any delay between the redefinition taking effect and |DUT1| exceeding 0.9s. The 1999 leap seconds looks like it was added a touch early. I'd heard from people at the time that they added it a little early so not to have a leap second on Dec 31, 1999 in the middle of y2k stuff. The trend lines show that would have been the better time to add it, all other things being equal. Does anybody know if this actually happened in fact? My sources were a little hand-wavy and vague when I heard about this around 2003 or so. However, given the tolerance of DUT1 is .9 and not .5, I'm sure that an extra last leap second could be tossed in to give vendors more time to cope... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Jan 31, 2011, at 11:33 AM, Poul-Henning Kamp wrote: > And you don't think a software update in the next 8-10 years could fix that > issue, given that DoD is likely to lean on the vendor to get this fixed ? "Fix" is not the right word for something that is not currently broken. That said, it is disingenuous to say there are 8-10 years. The notion appears to be that the redefinition of UTC will take effect 5 years after adoption. Presumably you are allowing not only for the 1.5 years until the vote, but also for a similar latency until the succeeding leap second would have occurred. This latency, however, is as likely to be negative as positive. With knowledge that the standard was due to change, it might well be the case that an earlier leap second during that 5 year window would be embargoed. Leap seconds have historically been scheduled as soon as possible: http://iraf.noao.edu/~seaman/leap (See the plot under "leap second scheduling.) There is no reason to believe that there will be any delay between the redefinition taking effect and |DUT1| exceeding 0.9s. At the other end, from the point of view of stakeholders (including DoD "vendors"), the clock will have been ticking for many months or even years before the issue is brought to their attention. Precious little ITU resources have been invested in UTC educational efforts over the past decade. That lack will become evident when the ITU has to deal with the fall-out from its hasty consensus-abjuring decision-making process. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon 2011-01-31T18:33:42 +, Poul-Henning Kamp hath writ: > And you don't think a software update in the next 8-10 years could fix > that issue, given that DoD is likely to lean on the vendor to get > this fixed ? A more relevant question is the likelihood of a successful result, and about that I can't easily opine. However, the issues with the system were unknown until I had extensive discussions with the vendor team. The DoD document which asserts that it would be okay to abandon leap seconds in UTC was signed before these discussions. That implies that DoD never asked such questions. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
In message <20110131182800.gx20...@ucolick.org>, Steve Allen writes: >We are not the only customers of this system. We understand that some >of these telescopes have been sold to DoD and other customers whose >usage of the telescope pointing system is for satellite tracking. I >doubt that their application can so easily tolerate a lie about the >longitude of their telescopes. And you don't think a software update in the next 8-10 years could fix that issue, given that DoD is likely to lean on the vendor to get this fixed ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Greetings Dave Finkleman, On Mon 2011-01-31T11:59:21 -0500, Finkleman, Dave hath writ: > I have convinced Wayne that a face to face meeting would clear the air. > I meet with him on Friday. I would appreciate a few examples of > specific commercial or system unique software that would be deprecated > if leap seconds and their more precise companions were deleted. I point out that the next ITAC-R meeting is Feb 3 so more policy may have been decided before Friday. I also send along this snip from his report as USSG7 chair which he just sent out in preparation for Thursday's meeting. The Chairman of SG-7 agreed to forward the revised ITU-R Recommendation TF.460 (elimination of leap second adjustments to UTC) to the Radiocommunication Assembly for consideration and approval. The Chairman, recognizing that SG-7 would not be meeting again prior to the Radiocommunication Assembly and that the areas of disagreement were philosophical in nature and not technical, proposed to send the DRR to the RA along with a detailed report describing the differing views. This adds more details to the information from Arias and Ohishi about the 2010 October SG7 meeting that I yesterday found in the web page of IAU Comm 31 activities. (And for today the SG7 delegation from Canada is my hero.) As a first answer to your question, we have a telescope with a closed-source control system which will not permit |DUT1| > 1.0 s. If leap seconds are removed from the time scale reported by the firmware in the GPS unit which provides input for telescope pointing then the only means we will have to keep the telescope pointed at the sky will be to systematically shift the value of the longitude of the telescope in its configuration file. Our use of the telescope is entirely celestial, so we can afford to lie about the terrestrial position. We are not the only customers of this system. We understand that some of these telescopes have been sold to DoD and other customers whose usage of the telescope pointing system is for satellite tracking. I doubt that their application can so easily tolerate a lie about the longitude of their telescopes. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On Mon, 31 Jan 2011, Finkleman, Dave wrote: > > BTW, the Moslem day begins at observable moon rise, which is different > than sunset. I think you mean that Islamic months begin with the first observation of the crescent moon after a new moon. Moonrise occurs at all times of day and is often not observable. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
