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-0dc35b4e8...@noao.edu>
Rob Seaman <sea...@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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
