In message: <Pine.LNX.4.64.0612270344160.6784_at_hermes-1.csi.cam.ac.uk>
Tony Finch <dot_at_dotat.at> writes:
: > The nature of the uncertainty is very different. The uncertainty of
: > future UTC can be managed, but for timezones the only sane path is to
: > eschew their use entirely.
:
: That isn't possible for applications like appointment books and job
: schedulers. As Warner suggests, you need to calculate future times
: provisionally, and in a way that insulates you from discontinuities.
: For example, "same time tomorrow" instead of "in 86400 seconds".
And 'same time tomorrow' might not exist depending on the timescale
that's used. Cron runs into this problem (and has solved it) because
it runs in localtime which has hours repeated or omitted twice a
year. Leap seconds are handled in an ad-hoc way as well, typically
the last second of the day is repeated for a positive leap-second so
cron jobs on fast machines that run at midnight UTC don't run twice.
There is a more subtle point that I should mention explicitly. The
folks that say "do everything internally as TAI time" tend to forget
that to do that one must restrict one's self in a number of important
ways. Because certain things are almost always in UTC time (IRIG
timecode, measurment of atomic clocks for BIPM UTC calculations, etc),
one must take care to know that when you convert a time into TAI from
UTC that you can then make the inverse computation and arrive back at
the same time. One must also know the appropriate TAI-UTC offset for
that time. Typically, one doesn't schedule things in these kinds of
systems too far in the future, and one's historical data processing is
handled offline where perfect historical knowledge of leap is
available for dealing with long or abnormal intervals.
Of course, needing to know TAI-UTC offsets leads one to interesting
situations. What does one do if one has TAI time, but not UTC and a
conversion is asked for? Is it right to pause that thread until it is
available, or is an exception right? Pausing the thread means that
less code has to deal with this ugliness and makes it so the
programmer doesn't have to know that time1 - time2 might fail
randomly. However, pausing can lead to deadlocks if the thread that
acquires this knowledge pauses. Throws in an exception avoids the
deadlock case, but makes every single time expression prone to having
to deal with exceptions, which can be tedious and time consuming to
code every single time. In C++ this can be really bad because
operators are often overloaded for time libraries to make the time
types look like native.
There are a number of sources of phase (rtc clock, UTC time, TAI time,
GPS time, NTP servers) and a number of sources of TAI-UTC (internet
ftp, GPS almanac, Loran Data Channel, local data file). The arrival
of the data from these sources may be asynchronous, and the cached
value may be too old to be useful (for spares that have been sitting
on the shelf for a few years). The data sources might be unavailable
because the device is cold starting, or because the antenna cable is
damanged. These different scenarios have different "right" things to
do. The data can also expire because that GPS antenna has been
damanged for too long and you don't know the next leap second is
coming...
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...
Warner
Received on Tue Dec 26 2006 - 23:04:43 PST