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