[LEAPSECS] Schedule for success

[M. Warner Losh]

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