D. J. Bernstein djb at cr.yp.to
Sat May 30 19:44:02 UTC 1998

(See http://pobox.com/~djb/proto/utctai.html for a quick introduction to
leap-second issues.)

Markus Kuhn writes:
> This means, a TAI clock is doomed to go wrong without
> periodic manual intervention

You have the situation precisely backwards.

For computers without any outside input, ticking UTC is impossible by
definition. Ticking TAI requires nothing more than an internal clock.

For computers with outside input, the inherent cost of an occasional
leap-second-table update is miniscule. Leap seconds are announced
several months in advance.

> Therefore, I favour UTC as a timescale in computer applications.

You have been outvoted by thousands of programmers who subtract UNIX
times to compute real-time differences.

> TAI is only of concern in very special
> purpose systems such as navigation and astronomical/geological observations.

Nonsense. One of the most basic code optimization techniques is to try
several code alternatives on an unloaded system and time each one to see
what's fastest. Many packages do this automatically during installation.
What happens if someone installs such a package during a leap second?

Saying ``well, they should use RDTSC or gethrtime() or CLOCK_RIGHT'' is
missing the point. They _don't_. Telling all of them to change, for the
sake of a minor simplification in xntpd, is poor engineering.

> Attosecond timescales are practically useless for the forseeable future.

Nanosecond timescales are woefully inadequate for certain applications.
Anyway, you should learn to read more carefully; /etc/leapsecs.dat uses
TAI64, which is an 8-byte scale providing 1-second precision.


More information about the tz mailing list