TAI64

[Markus Kuhn]

"D. J. Bernstein" wrote on 1998-05-31 03:44 UTC:
> I'm interested in what works, not in religious arguments.

Same here! 8)

> There's a huge amount of code that subtracts UNIX times to compute
> real-time differences. There's a much, much, much smaller amount of code
> that converts UNIX times to local times.

I am not sure this is really true: The code that subtracts time
usually semantically does things like t = t + "one day". If one day is
represented by (time_t)86400, then with the POSIX definition of time_t,
what you get is the same time on the next day, which is what users
usually expect, no matter whether there was a leap second in between or
not.

> > Your "computers without any outside input"
> > are after a couple of months *far* away from both TAI and UTC.
> 
> Actually, with most clocks, it's easy to keep the error below 1 second
> for the entire lifetime of the computer.

In my experience, this works only for computers in well air-conditioned
rooms that are rarely switched off. Opening a window in winter near my
PC causes the clock frequency to change 20 ppm due to the temperature
drop, i.e. your 1 s error has accumulated for a crystal calibrated during
a hot summer day in less than a day. I could even see the server room's air
conditioning duty cycle on the NTP log files of the stratum-1 server
at the University of Erlangen. For 1 sec error over a computer's lifetime
(say 5 years), you should better invest in a small oven that keeps the
crystal temperature controlled on one of the extrema of the crystal's
frequency versus temperature curve.

> False. Accurate time differences are often crucial whether or not the
> local-time display is accurate.

Accuracy of local time display is probably a cultural thing. When I was in the
U.S., I rarely saw anywhere a clock with accurate time display. Most were at
least 3-8 minutes wrong. The media doesn't broadcast any time signals, and if,
then they are often over a minute wrong (as seen several times at CNN HN). The
only sources of accurate time I have seen in the U.S. were NTP computers, GPS
receivers and my shortwave radio when tuned to WWV. In Europe, is is customary
that most radio and TV stations send beeps as a precise hour marker at the
beginning of the news and people set their watches accordingly. In Central
Europe, modern low-cost radio alarm clocks now typically contain a DCF77
receiver since the hardware costs of such a time receiver are just around 10
USD. Railway stations also have radio clocks with the precise time, as do many
church bell towers. Since local time with subsecond accuracy is available so
widely, users also like to see their computers to be as accurate as BBC and
their radio clock with regard to its time display. In the U.S. on the other
hand, GPS servers that displayed local time with the GPS-UTC offset added were
sold for quite some time without anybody even noticing that the displayed time
was off by several seconds. Please be aware that your personal opinion about
the desirability of accurate local time display might be seriously regionally
biased. In Europe, many people will immediately call support if their supposed
to be synchronized clocks are five seconds wrong compared to the radio news
beeps.

> > Feeding this information into computers then requires manual
> > intervention unless we establish some leap second history update
> > protocol for all computers on this planet.
> 
> False. A new protocol is not necessary, since NTP is able to transmit
> leap-second warnings. (However, a new protocol would be a good idea for
> several obvious reasons.)

Last time I looked at NTP, it only announced the next leap second and did
not say what the current TAI-UTC difference is. So NTP does not provide
the information to convert reliably between UTC and TAI. I guess, this
can and should be changed of course in the next NTP revision. Once this
is done, you will be able to select between at least four clocks formats
on a NTP host:

CLOCK_UTC shows UTC with leap seconds counting tv_nsec from 1e9 to 2e9-1
and is unavailable if the synchronization source has been interrupted
for some time. This is for highly reliable timestamps (e.g., financial
transaction systems, timestamping services, etc.)

CLOCK_TAI shows TAI without any leap seconds and is unavailable if
the synchronization source has been interrupted for some time. I don't
expect many systems to have CLOCK_TAI available. This is for
navigation systems, astronomers, geologists, etc.

CLOCK_MONOTONIC shows an always available second counter that never jumps and
that is not guaranteed to be related to any absolute time scale. This is what
t1-t2 programmers should use. It can be identical to CLOCK_TAI if CLOCK_TAI was
available at boot time, but it does not need to be. A typical PC implementation
will probably read the CMOS clock at boot, interpret the time in there as UTC
and then set CLOCK_MONOTONIC accordingly once and never correct its phase
later. The system is allowed to adjust the frequency of CLOCK MONOTONIC by up
to 200 ppm once the frequency error of the clock has been determined when
external synchronization becomes available.

CLOCK_REALTIME This is a best effort estimation of UTC that also takes t1-t2
usage in existing systems into account. This value is also returned by
gettimeofday(). It is low-pass filtered to smooth out leap second phase jumps
over a couple of minutes, and it continues to run freely even when CLOCK_UTC is
unavailable. It is adjusted to CLOCK_UTC once  available by changing its
frequency within 1 %. If the system discovers that CLOCK_REALTIME - CLOCK_UTC
is more than 1000 seconds off, then a syslog warning is issued and
CLOCK_REALTIME brutally jumps to CLOCK_UTC without smooting time. This brutal
jump should happen only once when the system is installed first. CLOCK_REALTIME
is a compromise for backwards compatibility with existing practice of t1-t2
gettimeofday() usage. New applications should use CLOCK_MONOTONIC instead where
available, because the rate of CLOCK_REALTIME can be up to 10000 ppm
off while the rate of CLOCK_MONOTONIC is typically much better than 200 ppm.

What is wrong with this clock API? POSIX.1b provides already the
interface for accessing several flavours of clocks, so why not just use
it?

> >   tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86_400 +
> >   (tm_year-70)*31_536_000 + ((tm_year - 69)/4)*86_400
> 
> Don't be an idiot. 2100 is not going to be a leap year.

Only an idiot would feel better after implementing leap second formula
for 32-bit time_t. The above formula as quoted from POSIX.1 was only
designed to work in the tm_year range 1970..2038 since time_t is on most
systems a signed 32-bit integer. Implementing the correct leap year formula
when using a 32-bit time_t would just demonstrate the programmer's
ignorance of the int overflow. But don't worry, a whole army of S2G
consultants is already waiting to set up the next generation of
panic web pages once we have survived Y2K. :)

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>