Re: Schreiver AFB warns about leapsec
- Original Message - From: Tom Van Baak [EMAIL PROTECTED] To: LEAPSECS@ROM.USNO.NAVY.MIL Sent: Tuesday, December 20, 2005 5:09 PM Subject: Re: [LEAPSECS] Schreiver AFB warns about leapsec While you're at it let's change when leaps occur; not just at 23:59:59 ... I second this too, 23:59:59 is the worst time to insert a leap second, since failing to implement it leaves you with the wrong day (month and possibly year) at the very second it occurs. Given the way Olympics are promoted these days, as well as stadium naming rights, billboards, web advertising, and google adwords, perhaps the ITU can get commercial sponsorship for future scheduled leap second events. Commercial interests have long since claimed trademarks on otherwise free letters, words, and symbols. So how about time itself? The income could be applied as grants to those trying to correctly implement and debug the growing global list of time interconnected technologies. And no small percent to astronomers so they have real-time precision access to UT1. Everyone is happy. (If this happens I will deny ever having suggested it). Coca-Cola is the official sponsor of the December 2005 leap second. The one second pause that refreshes. Panasonic is the official sponsor of the June 2007 leap second. Just slightly ahead of Earth time. /tvb WWV...You give us 22 minutes, we'll give you 21 minutes and 60 seconds. Brian
Re: Schreiver AFB warns about leapsec
In message [EMAIL PROTECTED], Francois Meyer writes: On Tue, 20 Dec 2005, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED] on.fr, Francois Meyer writes : I second this too, 23:59:59 is the worst time to insert a leap second, since failing to implement it leaves you with the wrong day (month and possibly year) at the very second it occurs. That is probably one of the strongest arguments for retaining that moment of insertion: That way computer bugs are more likely to be noticed. UTC is not a debugging tool, it is an international standard. Software is an an issue but I think it cannot justify in itself that leap second impact should be as large as possible. It must be wonderful to live in a world where software can just be ignored or marginalized at whim, I really envy you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Schreiver AFB warns about leapsec
There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS support center: https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/Leap_Second_Event.ppt Amongst the nuggets: Large error makes data unusable for some applications Eglin radar missed the leap second in 1998 Thousands of observations had to be discarded Problem was also evident at Clear However, host system software receiving the 23:59:60 time hack may not know what to do. System dependent response. They clearly know what the problem with leap seconds is :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Schreiver AFB warns about leapsec
On Dec 20, 2005, at 1:30 AM, Poul-Henning Kamp wrote:There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS support center:https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/Leap_Second_Event.pptAgreed. Very interesting.They clearly know what the problem with leap seconds is :-)Agreed, although they simplify leap seconds as being: - Needed to compensate for changes in earth’s rotationSuggest folks read the entire presentation, which delivers common sense advice without editorial comment. (That's our job.) The authors start by assigning the responsibility appropriately:- User’s realization of UTC could incorrectly step by one secondThey describe limits to the affected systems:- Leap second should not affect stand alone navigation or positioning (affects timing output of receiver) - Adjustment transparent to users with GPS receivers in compliance with IS-GPS-200 - Some receivers may require manual adjustment by users - Systems (military, civil, commercial) using GPS timing with a tolerance less than 1 second, might be [emphasis in original] impacted if leap second adjustment is not made properly (either automatically or manually)A hint that the issue may be more complicated than it appears: - Often, use of GPS timing in embedded systems is difficult to discern – consult your system engineers / expertsAn interesting observation:- Leap second occurs at an awkward time - New Years EveMaybe obscurity in scheduling and implementation is not a desirable characteristic after all. Perhaps the problem would "solve itself" through market forces if leap seconds were simply required to occur on normal business days at 9:00 am EST, just in time for the opening of the NYSEand they deal with the consequences pragmatically, rather than trying to legislate physical reality out of existence: - Contact your UE manufacturer to determine if your UE is IS-GPS-200D compliant with respect to leap seconds - Ensure documentation, procedures and personnel are in place to deal with potential problems - Monitor your system through the leap second event - Report if you have problems - We need to document so we can correct the problem for next eventIn addition to pondering how well such preparations would succeed for events three orders of magnitude larger occurring only every several centuries, this reader is left wondering what the corresponding presentation would look like if it were describing remediation to the same systems to support DUT1 0.9s.Rob SeamanNational Optical Astronomy Observatory
Re: Schreiver AFB warns about leapsec
On Dec 20, 2005, at 4:12 AM, Poul-Henning Kamp wrote: Maybe obscurity in scheduling and implementation is not a desirable characteristic after all. Perhaps the problem would solve itself through market forces if leap seconds were simply required to occur on normal business days at 9:00 am EST, just in time for the opening of the NYSE. They already happen during business hours in Asia. Since most of the US debt is owned by asia these days, it may even be a more efficient market pressure venue. I presume January 1 is a holiday for much of Asia, as well as in the West. The calendar for the Tokyo Exchange implies such (although January 1 has fallen on a weekend for the past two years): http:// www.tse.or.jp/english/guide/calendar.html. Not aware of any world holidays falling on July 1, but my (extensive) ignorance is no guarantee. So a quick estimate is that half of all leap seconds occur during the observance of a major world holiday in the great majority of localities, especially since North America, for instance, where the leap second occurs during the evening of local December 31 also observes New Year's Eve as a de facto holiday. And, of course, two- sevenths of the remaining leap seconds occur during weekends, and the remainder occur outside normal business hours in two-thirds of the timezones (including North and South America, Africa, and Europe extending well east). So yes, you can get leap seconds affecting the far east during business hours, but this occurs only something like 36% of the time. Would greatly appreciate knowledgeable comments from list members in Japan or Australia. This scheduling was a conscious design choice. I'm asserting it may not have been the right choice. Rob Seaman National Optical Astronomy Observatory
Re: Schreiver AFB warns about leapsec
In message: [EMAIL PROTECTED] Francois Meyer [EMAIL PROTECTED] writes: : On Tue, 20 Dec 2005, Rob Seaman wrote: : : On Dec 20, 2005, at 1:30 AM, Poul-Henning Kamp wrote: : : There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS : support center: : : https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/ : Leap_Second_Event.ppt : : Agreed. Very interesting. : ... : An interesting observation: : : - Leap second occurs at an awkward time - New Years Eve : : Maybe obscurity in scheduling and implementation is not a desirable : characteristic after all. : : The same paradigm suggests a new definition of UTC, : strengthening its link to UT1 down to 0.09s, and : switching from leap seconds to leap tenths of a : second. This aims at making leap intervals a rule : and not an exception. Tens of a second are as easy : (or as difficult) to implement as leap seconds, : their instantaneous impact is 10 times lower and : since only automated systems are really affected, : the increased frequency of their occurrence is not : an issue. I'd take issue that .1th of seconds are easier to implement, especially given that most of the timing gear today would have to be discarded because it isn't compliant. All the time signals would need to be redesigned. A lot of software would need to be rewritten to cope with the smaller offsets (not least ntp). There's a huge deployed base of gadgets that grok leap seconds as they are today and that would become obsolete. Not to mention that .1s jumps would make it harder to correlate data back to TAI (the tables you'd need are more complicated). .1s jumps would happen more often, so would be more unpredictable than the leap seconds we have today. My main beef with them is that we have no way of knowing today, with certainty, if there will be a leap second on June 30, 2006. The schedule is essentially random, which is a problem for devices that need to know utc-tai offset given an approximate time. I don't see how that would ever work. Warner
Re: Schreiver AFB warns about leapsec
Thanks for the link. I see the reference to it is on their main page: https://www.schriever.af.mil/GpsSupportCenter/advisories.htm Also note the leap second photos they used in the power point presentation came from: How to Watch a Leap Second http://www.leapsecond.com/notes/leap-watch.htm /tvb http://www.LeapSecond.com - Original Message - From: Poul-Henning Kamp [EMAIL PROTECTED] To: LEAPSECS@ROM.USNO.NAVY.MIL Sent: Tuesday, December 20, 2005 00:30 Subject: [LEAPSECS] Schreiver AFB warns about leapsec There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS support center: https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/Leap_Second_E vent.ppt Amongst the nuggets: Large error makes data unusable for some applications Eglin radar missed the leap second in 1998 Thousands of observations had to be discarded Problem was also evident at Clear However, host system software receiving the 23:59:60 time hack may not know what to do. System dependent response. They clearly know what the problem with leap seconds is :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
