Re: Who uses DUT1?
On Sat 2005-07-30T10:18:42 -0700, Tom Van Baak hath writ: > So my question is - is the actual value of DUT1, > as broadcast with single digit precision, still > used? And if so, from where do they get the > value? We do not use them for our telescopes at Lick, but our big telescope is built out of battleship-era technology. Pointing to within 15 arc seconds is quite acceptable for a telescope which is controlled by a human operator. This will change for the new telescope we are having constructed this year. It is to operate entirely autonomously. Its software system expects to download the predictions from the USNO website on a regular basis. Given that we are not writing the software, we do not know what sorts of alarm conditions it will set off if it cannot contact the internet for an extended period. The reports and proceedings of the IAU GAs in 1970 and 1973 make it clear what the concerns regarding DUT1 were. I suspect that the reports and proceedings of the CCIR from those years reveal the same thing, the differences being in who realized which things first. Initially the plan was to broadcast the difference from UT2, because it had been the practice since 1956 for the broadcasts to give UT2. The astronomers at the IAU GA in 1970 pointed out that for purposes of navigation it was UT1 which was relevant, because navigators already had to back out the UT2 correction to make most precise use of the broadcasts. In practice that detail was moot for the broadcasts because the value of |UT1 - UT2| never exceeds 0.35 seconds. The broadcast values of DUT1 were instituted along with leap seconds such that the radio broadcasts of time signals would remain just as useful to the typical limits of human-sighted sextant readings as they had been. That is to say, a skilled navigator might get to 50 meter accuracy under the best of circumstances. My unpracticed star shots were 20 times worse than that, so the DUT1 would never have benefitted me. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote: > >> I have three times been through what ended up being total reinstalls >> from backups because some operator by accident (or stupidity) set >> the clock forward in time and then backward in time on a database >> installation. > >Are you asserting that these problems had something - anything at all >- to do with leap seconds? No, they had everything to do with computers don't liking time to jump around. In order to test leapsecond handling, you need to jump the time forward to end of june or december, afterwards you need to jump it back. Since operating systems and databases in particular croak when you do that, testing for leapseconds is a major nightmare which takes very significant down time to accomplish. >Poor management of software >systems doesn't seem like a strong justification - or even >rationalization - for changing a completely unrelated international >standard. When you start out on a long march, you don't put a stone in your boot deliberately, and if one is there already, you take it out. Leapseconds is such a stone for real-world IT installations. >The solution to ignorance - what you so generously characterize as >"stupidity" - is education. I agree in principle, but who is going to pay for it ? And your plan looks a lot more feasible once you get a written confirmation from all operating system vendors that they will not release a product if the actual code has not correctly handled a real leap second. >You are really just supporting the tired >old notion of security through obscurity. As the traffic school cop >pointed out: there are no accidents, only collisions. Close, but no cigar: I'm pointing out that UTC with leap seconds is unsafe at any speed. >> Your workstation is not an "IT installation", it is just a >> workstation. > >I was our Y2K team lead. For that period of time, my workstation was >one of the primary development systems for an image processing >software package used by half the astronomers in the world. I'm sorry Rob, but this was what is normally called "a toy application" in the context of Y2K. >Why are we not discussing what new data structures, APIs, transport >protocols, deployed systems, operating procedures, staffing and >management issues will be necessary to implement such a major change >less than two-and-a-half years hence? How is it that this "proposal" >is completely devoid of any discussion whatsoever of its >implementation and ramifications? I think it is mainly because the people most in need of those facilities are being BHA's about the entire thing and therefore do not seem to prepare for the very likely situation that they won't get things their way. If I were a professional astronomer, I would be busy with all those things, but as it is, I have not a single computer anywere which will be negatively affected by missing leap seconds. In that situation I don't really see the political soundness in me imposing my ideas how to solve these problems on an astronomical community which doesn't seem receptive to the need. But if you find out that you're going to prepare for it, I'll be more than happy to assist anyway I can. Getting DUT1 into the NTP protocol would be one option (but unless stratum 1 servers can get hold of DUT1 it doesn't really help us that much). >UTC is the equivalent of ISO 8601 for the purpose of this never- >ending discussion. No, if that were so, it would be ISO that decided the fate of leap seconds. As it is, ISO8601 references UTC and is therefore based on UTC. >In point of fact, many ISO 8601 compliant strings >embedded in your databases implicitly assert that UTC ~ GMT. Doesn't that mean that your database contains baseless assumptions ? As I said earlier: it sounds a lot to me like astronomers made a blunder when they used UTC without realizing that the properties of that timescale is not in their control. It would have been much smarter to use TAI, wouldn't it ? I thought I heard some astronomer say in this discussion that all applications which need proper timekeeping should use TAI ? >Whatever happens to leap seconds in the future, proper interpretation >of your archival records will continue to depend on interpolating the >appropriate leap seconds. You mean "just like the rest of astronomys N thousand years of records ?" Some years ago I read with great interest about the problems trying to nail Tycho Brahes observations to a usable timescale, and I can't for the life of me think that the necessary interpretation of UTC is any harder. And if anything, if astronomers switched to TAI on 2008-01-01 they would not run into this problem in the future. >Or actually - not. Precisely because UTC >~ GMT, typical civil usage allows you to completely ignore leap >seconds when interpreting past data records. Are you saying the reason we have leap seconds is because they allow astronomers to b
Re: Who uses DUT1?
In message <[EMAIL PROTECTED]>, Tom Van Baak writes: >WWV and WWVB and perhaps other national >systems transmit DUT1 as a 3- or 4-bit signed >number of 100 ms. As does MSF/Rugby in the UK. -- 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: Leap-second scare stories
I can confirm that the text below is identical to the official proposal on 7A's table. (I have seen the official document, but cannot redistribute it).For the record, I can confirm that I got the document from an openly visible place on the web which Google knew about.A focus on such trivial bureaucratic issues is usually a good sign that a proposal is headed down the tubes. One hopes that this holds true in this case. Perhaps the issue can be reborn as it should have been from the beginning: an open discussion among all parties interested in the full scope of how to improve the delivery of time signals of all types for all purposes. Address these issues first and the question of what particular time scale should form the foundation of civil time should become clear to all.Rob SeamanNational Optical Astronomy Observatory
Re: Leap-second scare stories
On Sat 2005-07-30T19:04:43 +0200, Poul-Henning Kamp hath writ: > I can confirm that the text below is identical to the official > proposal on 7A's table. (I have seen the official document, > but cannot redistribute it). For the record, I can confirm that I got the document from an openly visible place on the web which Google knew about. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Leap-second scare stories
A very apt case study has been provoked by the WSJ story. Slash-dot is a gathering of IT-geeks of various sorts, but mostly the dot-com generation. See how well they grasp leap-seconds http://slashdot.org/article.pl?sid=05/07/30/135239&threshold=3&tid=103&tid=164 (I caution against setting a threshold lower than 3: below that is a lot of beavis & butthead quality noise.) -- 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: Leap-second scare stories
Markus Kuhn scripsit: > We must be talking about different proposals then. So it seems. I of course agree that leap hours in UTC are a terrible idea. -- Principles. You can't say A is John Cowan <[EMAIL PROTECTED]> made of B or vice versa. All mass http://www.reutershealth.com is interaction. --Richard Feynman http://www.ccil.org/~cowan
Re: Wall Street Journal Article
On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote:I have three times been through what ended up being total reinstallsfrom backups because some operator by accident (or stupidity) setthe clock forward in time and then backward in time on a databaseinstallation.Are you asserting that these problems had something - anything at all - to do with leap seconds? If you were the one cleaning up the mess, presumably you had something to do with hiring the operators and documenting their operating procedures. Poor management of software systems doesn't seem like a strong justification - or even rationalization - for changing a completely unrelated international standard.The solution to ignorance - what you so generously characterize as "stupidity" - is education. You are really just supporting the tired old notion of security through obscurity. As the traffic school cop pointed out: there are no accidents, only collisions.Your workstation is not an "IT installation", it is just a workstation.I was our Y2K team lead. For that period of time, my workstation was one of the primary development systems for an image processing software package used by half the astronomers in the world. The astronomical community responded promptly and appropriately to Y2K, with initiatives such as formally adopting ISO 8601 and introducing pivot dates into systems that had to remain backwards compatible. Coherent APIs were designed and implemented to handle both new format and old format date/time strings transparently.Why are we not discussing what new data structures, APIs, transport protocols, deployed systems, operating procedures, staffing and management issues will be necessary to implement such a major change less than two-and-a-half years hence? How is it that this "proposal" is completely devoid of any discussion whatsoever of its implementation and ramifications?UTC is the equivalent of ISO 8601 for the purpose of this never-ending discussion. In point of fact, many ISO 8601 compliant strings embedded in your databases implicitly assert that UTC ~ GMT. Whatever happens to leap seconds in the future, proper interpretation of your archival records will continue to depend on interpolating the appropriate leap seconds. Or actually - not. Precisely because UTC ~ GMT, typical civil usage allows you to completely ignore leap seconds when interpreting past data records. Rather, proper interpretation of your *future* database records may well require explicit time scale conversions. There is a vast web of implications associated with civil time. Trying to sneak through a major change of philosophy to an international standard simply to avoid having to think about its implications seems craven and intellectually dishonest.Why are tired, inaccurate and unconvincing leap second risks treated like plutonium is raining from the sky? And why are the subtle and real risks associated with violating the implicit assumption that civil time corresponds to Greenwich Mean Time ignored completely? GMT - and its successor, UTC - is a standard that has been in place since the nineteenth century. Wouldn't it make sense to conduct a risk analysis in advance of violating that standard worldwide?Rob SeamanNational Optical Astronomy Observatory
Who uses DUT1?
WWV and WWVB and perhaps other national systems transmit DUT1 as a 3- or 4-bit signed number of 100 ms. I'm curious what sort of instruments or operational systems use or used this value? Several astronomers on the list make a good case that they depend on UTC being close enough to UT1 for their work. So my question is - is the actual value of DUT1, as broadcast with single digit precision, still used? And if so, from where do they get the value? It's hard for me to imagine they would get it from WWV/WWVB; reception is not always good and these signals are not available outside the US; astronomy is an international effort. Outside the parts the world with LF timecodes, neither cellphones nor GPS transmit DUT1 so it makes me wonder if anyone uses it? I'm not looking for an argument; just wondered if there are photos or anecdotes of equipment that uses DUT1. It seems that if someone wanted DUT1 for an application these days it would be far easier to get it off the web. The internet is available in far more places in the world than an LF timecode. In addition, if one fetched it from IERS you'd get DUT1 to 10 us resolution instead of 100 ms, and past as well as future predictions. /tvb http://www.LeapSecond.com
Re: Leap-second scare stories
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >the one submitted by the US >delegation to ITU-R working party 7A on 1 September 2004 >(Document 7A/15-E), which I understand to be identical with: I can confirm that the text below is identical to the official proposal on 7A's table. (I have seen the official document, but cannot redistribute it). >1 Tolerance > >The difference of UT1 from UTC should not exceed =B11 h. > >2 Adjustments to UTC > >2.1 Adjustments to the UTC time scale should be made as determined by >the IERS to ensure that the time scale remains within the specified >tolerances. > >2.2 The IERS should announce the introduction of an adjustment to the >UTC time scale as least five years in advance. At the time of the >announcement the IERS should provide directions regarding the details of >the implementation of the adjustment. While the 5 year notice is a nice gesture, the real point is that we have 500 years to come up with a better idea before a one hour adjustment applies first time. -- 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: Leap-second scare stories
"John.Cowan" wrote on 2005-07-30 15:35 UTC: > > Let's not forget that this proposal is all about replacing a > > reasonably frequent minor distruption (UTC leap seconds) with a very > > rare catastrophically big one (UTC leap hours). > > No, it's about replacing an irregularly scheduled minor glitch in > what should be a uniform time scale with irregularly scheduled > major glitches in time scales (the 400-odd LCTs worldwide) that > no one expects to be either uniform or predictable, but where > measures to deal with these problems are already very much in place. We must be talking about different proposals then. The one discussed by the WSJ article is, as I understood it, the one submitted by the US delegation to ITU-R working party 7A on 1 September 2004 (Document 7A/15-E), which I understand to be identical with: http://www.cl.cam.ac.uk/~mgk25/time/leap/PropRevITU-RTF460-6.pdf http://www.ucolick.org/~sla/leapsecs/PropRevITU-RTF460-6.doc http://www.ucolick.org/~sla/leapsecs/gambis.html This one very much proposes to introduce leap hours into UTC, to be announced by IERS 5 years in advance (page 8): -- 1 Tolerance The difference of UT1 from UTC should not exceed �1 h. 2 Adjustments to UTC 2.1 Adjustments to the UTC time scale should be made as determined by the IERS to ensure that the time scale remains within the specified tolerances. 2.2 The IERS should announce the introduction of an adjustment to the UTC time scale as least five years in advance. At the time of the announcement the IERS should provide directions regarding the details of the implementation of the adjustment. 2.3 All operational rules and nomenclature prior to UTC December 21, 2007 given above no longer apply. Notes: (1) The broadcast of DUT1 will be discontinued. (2) Analysis of historical observations of the Earth's rotation currently indicates that such an adjustment would not be required for at least 500 years. -- I have only mild objections to simply going straight to atomic time (e.g., the TI proposal that was discussed at Torino). But a proposal like the one on the table at present, which attempts to camouflage the move to atomic time as merely a simple relaxation of the UTC tolerance by a factor 4000 from |UTC-UT1| < 0.9 s to |UTC-UT1| < 1 h is a recipe for catastrophes and therefore unlikely to ever be implementable. I consider such proposals illegal under Truth-in-Advertising legistation. They are a political trick. They are an attempt to make the change to UTC look less severe than it really is. If someone submits a proposal for discontinuing leap seconds, then it should say that |UTC-UT1| will from now on be allowed to grow unbounden, and they should choose a name that does not contain the astronomical term "Universal Time". Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Leap-second scare stories
Markus Kuhn scripsit: > I'm sorry, but I find these three badly documented second or > third-hand rumours of leap-second scare stories neither very scary nor > very convincing. No more they are, and thanks for the pointers to debunking articles. > It introduces leap hours into a time scale (UTC) that is so widely > used in computer networks exactly *because* (unlike civilian local > time) it is free of any disruptive DST leap hours! This, however, is itself badly in need of debunking. AFAICT, *nobody* is proposing the insertion of whole hours into universal time (lower-case generic term) either now or in a few centuries. Rather, the proposal is that as the difference between a particular LCT and the corresponding LMT becomes uncomfortably large, a change in the offset between universal and LCT can be made. This can happen piecemeal at the convenience of the citizens of various countries rather than top-down by fiat, as leap seconds are inserted now. And considering that the LCT of Kashi in China is near enough the LMT of Qingdao, some 44 degrees to the east, people are already tolerating differences you and I might call uncomfortably large. In the end numbers on a clockface are just numbers on a clockface, and though it can be annoying that one's daytime is spread over two different calendar days (already true for me who is rarely in bed before midnight LCT, and even more true for shiftworkers), one can live with it. > Let's not forget that this proposal is all about replacing a > reasonably frequent minor distruption (UTC leap seconds) with a very > rare catastrophically big one (UTC leap hours). No, it's about replacing an irregularly scheduled minor glitch in what should be a uniform time scale with irregularly scheduled major glitches in time scales (the 400-odd LCTs worldwide) that no one expects to be either uniform or predictable, but where measures to deal with these problems are already very much in place. -- Newbies always ask: John Cowan "Elements or attributes? http://www.ccil.org/~cowan Which will serve me best?" http://www.reutershealth.com Those who know roar like lions; [EMAIL PROTECTED] Wise hackers smile like tigers. --a tanka, or extended haiku
Re: Leap-second scare stories
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >> And in 2003, a leap-second >> bug made GPS receivers from Motorola Inc. briefly show customers the >> time as half past 62 o'clock. > >It conveniently omits the minor detail that this long preannounced >Motorola software bug actually manifested itself on 27 November 2003 >and was not in any way caused by an added leap second, but by an >unwise design choice in the GPS data format and a resulting counter >overflow. Obviously, if leapseconds hadn't existed in the first place, this bug would not have happened, because Motorola would not have included the buggy code in the receiver. And it is a very good example of exactly the kind of computer problem leap seconds give rise to: code that only gets executed once in a blue while, but not often enough to allow manufacturers to test it comprehensively before shipping products. >and was later only slightly elaborated by Peterson in > > http://www.maa.org/mathland/mathland_7_21.html > >where he admits that he "never could find out precisely why the >problem had occurred and who was responsible for it". Again, another good example of the computer problems leapseconds causes: If something goes wrong with leapsecond handling, you have to wait an indeterminate amount of time before you can get to see if you have managed to fix the problem or to collect more diagnostic information. -- 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.
Leap-second scare stories
Steve Allen wrote on 2005-07-29 21:37 UTC: > http://online.wsj.com/article_email/0,,SB112258962467199210-H9je4Nilal4o52nbYCIbq6Em4,00.html The article repeats an old urban legend: > In 1997, the Russian global positioning system, known as > Glonass, was broken for 20 hours after a transmission to the country's > satellites to add a leap second went awry. This contradicts statements found in the GLONASS operational bulletin quoted on http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00086.html The second scare story is: > And in 2003, a leap-second > bug made GPS receivers from Motorola Inc. briefly show customers the > time as half past 62 o'clock. It conveniently omits the minor detail that this long preannounced Motorola software bug actually manifested itself on 27 November 2003 and was not in any way caused by an added leap second, but by an unwise design choice in the GPS data format and a resulting counter overflow. So I wonder, how much factual substance there really is behind the claim > On Jan. 1, 1996, the addition of a leap second made computers at > Associated Press Radio crash and start broadcasting the wrong taped > programs. It seems to go back to a very anecdotal second-hand remark by Ivars Peterson in http://catless.ncl.ac.uk/Risks/17.59.html#subj1 which got quoted by Peter Neumann in ACM SIGSOFT Software Engineering Notes, March 1996, p.16 http://doi.acm.org/10.1145/227531.227534 and was later only slightly elaborated by Peterson in http://www.maa.org/mathland/mathland_7_21.html where he admits that he "never could find out precisely why the problem had occurred and who was responsible for it". I'm sorry, but I find these three badly documented second or third-hand rumours of leap-second scare stories neither very scary nor very convincing. Perhaps people should try to invent UTC leap-hour scare stories for a change. They should be at least 3600x more disruptive! Stardate 2651-12-31T24:08:16Z, Captain's log. About eight minutes ago, we experienced a sudden and entirely unexpected catastrophic failure in all our computers that forced us to abandon ship. We had just returned from a 6-year deep space assignment and entered a geostationary orbit over the Atlantic (39 degrees west), when all of a sudden the ship's primary and all backup clock networks failed, just as we reconnected to the Internet. A warp-core breach is now immanent and my science officer predicts that the resulting overwhelming electromagnetic pulse will instantly destroy all computers located on planet Earth between longitudes 126 degrees west and 48 degrees East; most of the Western hemisphere. > Ending leap seconds would make the sun start rising later and later by > the clock -- a few seconds later each decade. To compensate, the U.S. > has proposed adding in a "leap hour" every 500 to 600 years, which > also accounts for the fact that the Earth's rotation is expected to > slow down even further. That would be no more disruptive than the > annual switch to daylight-saving time, said Ronald Beard of the Naval > Research Laboratory, who chairs the ITU's special committee on leap > seconds and favors their abolishment. "It's not like someone's going > to be going to school at four in the afternoon or something," he said. It introduces leap hours into a time scale (UTC) that is so widely used in computer networks exactly *because* (unlike civilian local time) it is free of any disruptive DST leap hours! Let's not forget that this proposal is all about replacing a reasonably frequent minor distruption (UTC leap seconds) with a very rare catastrophically big one (UTC leap hours). Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jul 29, 2005, at 2:11 PM, Poul-Henning Kamp wrote: > From 1998 to 1999, I left the clock on my desktop Sun workstation >set forward 11 years. This allowed me to test various Y2K >remediation issues. (The 11 years was to select the next year with >the same monthly calendar.) There is nothing untestable about leap >seconds in either theory or practice. I have three times been through what ended up being total reinstalls from backups because some operator by accident (or stupidity) set the clock forward in time and then backward in time on a database installation. Your workstation is not an "IT installation", it is just a workstation. -- 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.
