On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote:
Calculating time intervals for times 6+ months in the future can be
the least of one's worries when one tries to code up a library to deal
gracefully with these different failure modes. The trivial case where
one has perfect knowledge of TAI-UTC and one can keep that knowledge
current is very simple in comparison. Dealing with this case is very
simple, and is the way most people think about leap seconds. But
dealing with the edge cases can be difficult because there are so
many, and so many that people forget to test or conceive of until the
call from the field comes in with a failure...
A lot of these edge cases are really firmly centered in issues of
real-time programming. Few versions of Unix are equipped to deal
with real-time issues in even a rudimentary fashion. In any event,
these cases have very little to do with leap seconds or any other
aspects of the representation of time quantities.
That said, I've found the current discussion immensely refreshing.
If there is to be any common ground found between the different
factions on this list (including the lurkers who actually have a vote
on ITU matters), it will be located by focusing on the actual
technical design process, not some quick fix gimmick.
1) Who are the stakeholders for civil timekeeping? (A discerning
eye might note that all this time we have NOT been arguing about TT,
etc.)
2) What minimal inventory of timescales will satisfy all stakeholders?
3) What economic, legal, historical, cultural, scientific, etc.,
requirements are placed on the delivery of said timescale(s)?
4) What technical solution(s) satisfy the requirements?
5) If change is deemed to be warranted, how best should it be
accomplished? (Funded, scheduled, designed, implemented, deployed,
maintained, supported, etc?)
My initial position for #2 is that there must be at least two
timescales, representing interval time and time-of-day, but in the
extreme one could even imagine a coherent position stating that NO
common international civil timescale is needed at all. (Whether one
holds this point of view may say more about ones view of civil
society than it does about civil timekeeping :–)
In the latter case, let UTC continue as it is, complete with leap
seconds. Let facilities derived from ITU deliberations start
distributing, for example, a refinement of GPS time. And let some
new consortium adopt the distribution of UTC, perhaps with many of
the improvements folks have suggested. (This would provide a chance
to do over - wouldn't that be lovely?) And then let the market
decide.
In the U.S., one would expect funding proposals for a new-and-
improved UTC to result. Those of us who aren't Co-I's would likely
be referees...
Whatever the solution, implementing it is unlikely to prove a
panacea. In the seven years this list has been in existence, we've
only scratched the surface of the complexities inherent in civil
timekeeping. In short:
6) Where should the lines of elegant design and rational compromise
be drawn?
Rob Seaman
NOAO
