[LEAPSECS] Schedule for success

[Rob Seaman]

Without trivializing the details, what you are describing could  
equally be taken as an argument for getting rid of GPS :-)  Nobody is  
suggesting this, since GPS is useful.  I'll skip my disclaimer about  
there being two kinds of time, but if a system requires two timescales  
then it must handle the edge cases.  And if it doesn't require two  
timescales, the edge cases shouldn't appear.  Your edge cases  
themselves remind me of similar issues with astrometric solutions.   
Getting these right can be a challenge.  That doesn't mean that there  
isn't a requirement to get them right.

However, your description is similar to nothing so much as arguments  
against using the metric system that focus on a bunch of paradigm  
smashing conversions to avoirdupois.  The point I was trying to make  
was that the ITU could simply focus exclusively on GPS.  As I said,  
the standard time issue would then be a separate question and you  
would be free to make a case for your point of view.  In fact, the ITU  
could pawn off standard time on some other organization entirely.   
Don't they only care about telecommunications infrastructure?  Aren't  
they the ones claiming that civil timekeeping is something else  
entirely?

In the mean time, you presumably wouldn't have to pay a 20 minute  
penalty if you aren't using the UTC features.  Considering that the  
ITU's vision of UTC in the future still wouldn't be GPS, it is by no  
means clear that the 20 minute overhead would go away.  Sounds like  
another good issue to explore to improve the proposal.

Why does the ITU itself appear to dislike GPS?

Rob
---

On Dec 31, 2008, at 10:40 AM, M. Warner Losh wrote:


> In message: <EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5 at noao.edu>

>            Rob Seaman <seaman at noao.edu> writes:

> : Steve Allen wrote:

> :

> : > We have seen that the international timekeepers of the BIPM get  

> livid

> : > when someone suggests that GPS time could be used in an official

> : > sense.

> : > The IERS seems to be a bit more mellow.

> :

> : Does anybody have insight into what the real issue is with simply

> : adopting GPS time?  It has long seemed that UTC is simply caught  

> in a

> : crossfire between two factions of the precision timekeeping  

> community.

> :

> : If the ITU position were simply to stop distributing UTC and to  

> start

> : distributing GPS (or some TI = GPS offset to avoid a jump), this  

> whole

> : debate we are having would simply go away.  We'd work around the new

> : standard.  Whether or not standard time would end up layered on UTC/

> : GMT or on GPS/TI would make for an entertaining discussion, but it

> : would be a very different discussion.

> :

> : Rather, the ITU is seeking to redefine UTC, and apparently GMT,

> : perhaps just as some gambit in a funding war or academic dispute.

> :

> : What's wrong with GPS?  Astronomers use it all the time, very

> : productively.

>

> In the software that I wrote, I adapted a time scale similar to GPS

> time.  There were no leap seconds in this time scale.  This made the

> high precision math that was used to measure clocks and the like work

> out in the face of leap seconds.  It made sure that certain measuring

> events happened at the right time or the right interval.

>

> However, it presented a number of challenges.  The biggest one was

> that you had to know the number of leap seconds for the current time

> before you could start up.  Either you were fed the GPS time, in which

> case you needed them to display the UTC time to the user, set the

> atomic clocks to the proper UTC time, get ntpd going with the proper

> UTC time, etc.  Or you had UTC time and didn't know the offset to the

> GPS time and had to wait for it to start the rest of the system.

>

> While knowing this seems trivial, it is anything but for many common

> scenarios.  The data is in the GPS stream, but a cold receiver can

> take up to 20 minutes to deliver this data, which interferes with the

> startup time specifications we had to meet.  For systems that didn't

> have a GPS receiver, there's no widely deployed way to get this data.

> NTP can provide it, but most NTP servers don't (and if you are an NTP

> server that's disconnected, it can be hard to fabricate the necessary

> tables).  There's ftp sites on the net that one can get it from, but

> firewalls in the way often times in the installations I've used.  One

> can mitigate these effects somewhat (knowing when you last knew when

> the next leap second could be would help all but the coldest of spares

> pulled off the shelf cases), but there are still edge cases that

> remain.

>

> Plus, even though we were using C++ that provided a number of

> different ways to try to get the time scale right all the time,

> several ways were found to slip through the cracks.  Time scale

> confusion was often a subtle bug to find (but easy to spot: my times

> are off by 34s!).  The multiplicity of the time scales also increased

> the complexity of the programs.

>

> In addition, we found that it was hard to exhaustively test different

> leap second scenarios.  In one set of tests we thought we'd covered

> everything (both positive and negative leap seconds).  However, we

> neglected the case where there was no leap second at the prior leap

> second opportunity (meaning December or June) and there's no leap

> second this opportunity, then bad things would happen due to an array

> overflow.  There were many other similar bugs that were found outside

> of testing, but this one illustrates the complexities that are faced

> when trying to get this pedantically correct for all cases.

>

> So if there were multiple time scales propagated, there would still be

> these problems so long at UTC was mandated anywhere in the system

> design.

>

> These are some of the practical problems associated with having to

> cope with multiple time scales.  I'm sure there are many others.

>

> Warner