[LEAPSECS] ISO TC 37

[Warner Losh]

On Jan 18, 2012, at 8:58 AM, Rob Seaman wrote:

>> but I sure hope that astronomers wake up, stop complaining,

> 

> 

> This is illogical (and borderline insulting).  We're supposed to "wake up", but do so without talking about the issues?

> 

>> and use UT1 and DUT1 for what they were designed for.

> 

> 

> Rather, Universal Time was designed as a successor to Greenwich Mean Time.


Universal Time is an abstract definition.  It wasn't designed at all.  It models the time of day, on the average, of an important historical observatory in a nation that had the political clout to get its observatory named primary over all the other nations that had good observatories that wanted the honor.  Newcomb's equations of time are just this.


>  UT1 is one realization of UT.  UTC is (currently) another.  If you require UT to a precision of about a second, DUT1 is not needed at all.


Who has an actual requirement for an approximation of UT to 1s?


> Since it was unnecessary, it was not built into large numbers of systems that would now need to be retrofitted.  This is non-trivial and will introduce bugs and dependencies on currently non-existent infrastructure.  (http://www.cacr.caltech.edu/futureofutc/preprints/38_AAS_11-678_Allen.pdf)


It is interesting to note that this states that in about a year the absence of leap seconds would cause problems for the 10m Keck reflector after about a year, but the average time between leap seconds is 18 months.  This suggests that telescope already is operating beyond the design parameters of UTC, or this claim is an exaggeration or lacks the appropriate disclaimer "after DUT1 exceeds 1s". (page 5)  Similar statements are made for other telescopes.

While I have no doubt that there will be issues, overstating them on time scales less than the current leap second rate and not providing an approximate DUT1 where problems occur does lessen the strength of the argument contained here.


> Meanwhile, those systems that do currently include DUT1 will require a Y2K-like vetting for values that exceed 0.9s.  (http://www.cacr.caltech.edu/futureofutc/preprints/36_AAS_11-677_Seaman.pdf)

> 

> It will bother the astronomical community to the tune of many millions of dollars.  It will bother the aerospace communities perhaps hundreds of millions of dollars:

> 

> 	http://www.cacr.caltech.edu/futureofutc/preprints/28_AAS_11-673_Simpson.pdf

> 	http://www.cacr.caltech.edu/futureofutc/preprints/30_AAS_11-674_Storz.pdf

> 	http://www.cacr.caltech.edu/futureofutc/preprints/32_AAS_11-675_Malys.pdf

> 

> Nobody else has been advised to look.


When the 2006 leap second happened, I happen to know of at least one company that spent about a million dollars to ensure that all their systems properly worked with the impending leap second.  Bugs were found in the software (since untested software is buggy software), the GPS receivers, and some third party gear that had been integrated in to their systems.  We were a small company (sold a few years later for $12M), and I'm sure that we weren't the only company that experienced costs associated with that leap second.


> Atomic time is already available to be used for what it was designed for.  This proposal adds nothing we don't already have, rather it subtracts something we do have.


As we've been over many times, the non-uniform radix of UTC causes problems for everybody that assumed a uniform radix.  This assumption is deeply ingrained in the software community, and UTC's redefinition of time in 1971 has yet to be fully apprehended in the literature and standards promulgated by different organizations.  You'd think that after 40 years that this non-uniform radix would have been fully integrated into systems, yet it is barely functional in only a few systems.  Yet experience has shown that people just know that minutes always have 60s, and getting them to be pedantically correct continues to be a significant challenge.

Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20120118/08d0e552/attachment.html>