On Jan 9, 2014, at 5:50 PM, Brooks Harris wrote: > Hi Rob, > > > On 2014-01-09 04:18 PM, Rob Seaman wrote: >> On Jan 9, 2014, at 4:58 PM, Brooks Harris <[email protected]> wrote: >> >>> Well, its clear the "end game" would take a long time to realize. It will >>> take serious patience on the part of folks who care. >> We’re halfway there, then ;-) This conversation has been going on for a >> very long time. > Yes, I know. > >> Click through to the archives for the current list and for the original >> leapsecs list from: >> >> http://www.cacr.caltech.edu/futureofutc/links.html >> >> The place to start before making a foray into the mailing list, however, is >> with Steve Allen’s excellent pages: >> >> http://ucolick.org/~sla/leapsecs/ > > Yes, I'm aware of and read much of it. Its a great collection of the issues. > >> >>> My point is that the standards, where they exist, are dispersed and >>> fractured. >> Indeed. They are also contingent on physical context from the real world. >> It is simple fact that a single time scale is insufficient to model the >> complexity of the systems required. > > Agreed. But a consistent "civil time" seems to be where the break-downs occur > and what has lead to the call to "eliminate Leap Seconds". This is in no > small part due to the know inadequacies of POSIX and NTP. So I think some > effort to better unify the behavior of "civil time", partly by better > documenting UTC's role in "civil time" would go a long way towards relieving > this pressure.
Until leap seconds can be represented in POSIX, and that's an incompatible change, the pressure won't go away. Time in computers simply doesn't understand leap seconds, and many ad-hoc hacks have been necessary to make them mostly cope. However, something has to give when this happens: Either accuracy in realization of the second, or the monotonic properties of time. Even worse, intervals across such events get fuzzy as well as calculation of future times is limited to 6 months. It isn't a lack of understanding that's causing the problems. It is a standardized disconnect. Oh, then there's the whole 'who cares about a second' so many things break in small ways around leap seconds, which makes it hard to get them right. And then there's the frustration of proposing less insane leap second promulgation that still keeps time in sync, over the long term, but allows for the possibility of DUT1 > 1s (but not unbounded). DUT1 < 1s is only convention and was selected somewhat arbitrarily. .1s was proposed, because that's the threshold of human perception, but that was rejected. After much back and forth, 1s seems to have been accepted because, well, navigation gives only a small error at 1s. The error would be larger at 2s, but still likely acceptable for most things... Announcing leap seconds 10 years out would solve many of the 'nobody knows that it is coming' issues since that would move the timeline of leap seconds from being less than the lifetime of deployed software to being greater than it (in most cases, outliers will still occur). It would also take the time horizon from < 1 year to > 1 year so that managers will know when leaps will happen and won't have to schedule extra, unplanned work. >>> So, an effort to simply consolidate the terms, definitions, and standards >>> into a single reference document would go a long way toward lending clarity >>> to system implementers, other industries, and, importantly, to governments >>> seeking to refine their laws to coordinate time and commerce with other >>> jurisdictions. >> Maybe a reference library is a reasonable place to start rather than a >> single document. I’m biased, but not therefore wrong, in recommending the >> proceedings of the 2011 and 2013 UTC meetings: > > Well, when I say "document" it might not take the form of a single document - > it could be several coordinated publications. My point partly is it needs to > created by due-process. > > nMaybe, just maybe, if enough experts rallied around a common due-process > document, then maybe, just maybe, the ITU might take a fresh look at it, and > maybe, just maybe, they'd consider refinements to the UTC specs like you've > suggested. And maybe, just maybe, the call to kill UTC would fade away. Until the operational issues with 'surprise leap second' goes away, and until there's a widely adapted, standardized way to represent time in computers that displaces time_t, I don't think you'll see calls for leap seconds to be improved or go away ending... Basically, the standards have forced great expense to support leap seconds, when in fact an alternative would be for wider DUT1 distribution and integration into systems. Many proprietary systems, alas, won't tolerate this so the astronomers complain that a change like this would idle their telescopes. No comprehensive study has been undertaken to show a balanced approach. To date, I've seen individual impacts of eliminating them from astronomers, but no industry wide study for how much software costs would be saved. So while I applaud your efforts to get better understanding, I'm pessimistic that it will have the goals you wish to achieve. Warner > >> >> Decoupling Civil Timekeeping from Earth Rotation: >> >> http://futureofutc.org/2011/preprints/ >> >> Requirements for UTC and Civil Timekeeping on Earth: >> >> http://futureofutc.org/preprints/ >> >> The published proceedings are available from the American Astronautical >> Society: >> >> http://www.univelt.com/Science.html >> >> As well as this week’s well attended American Astronomical Society splinter >> meeting: >> >> http://futureofutc.org/aas223/ > > Thanks very much. I've read some of these and I'll review them all. > > -Brooks > >> >> Rob Seaman >> National Optical Astronomy Observatory >> >> _______________________________________________ >> LEAPSECS mailing list >> [email protected] >> http://six.pairlist.net/mailman/listinfo/leapsecs >> >> > > _______________________________________________ > LEAPSECS mailing list > [email protected] > http://six.pairlist.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
