TAI64

[D. J. Bernstein]

I'm interested in what works, not in religious arguments.

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 want accurate local-time displays. I need accurate real-time
differences. I solve both problems by setting my UNIX clock to TAI-10:

   * http://pobox.com/~djb/clockspeed.html converts NTP to TAI-10;
   * the tz library converts TAI-10 to right/US/Central local time.

Unlike Kuhn's pie-in-the-sky suggestions, this all works _right now_.
I don't have to convince thousands of programmers to abandon ``t1-t0''.

Of course, when a new leap second is announced, I have to regenerate
several hundred zone files, using source that wasn't shipped with my OS.
I can deal with this. Most users can't. What I'm suggesting is that tz
read leap-second data from a single file, such as /etc/leapsecs.dat.

Markus Kuhn writes:
> 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. The real issue is instability,
not inaccuracy; any serious clock-handling program will compensate for
inaccuracy given two time measurements.

> These computers are therefore not of any concern here,

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

> 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.)

> > You have been outvoted by thousands of programmers who subtract UNIX
> > times to compute real-time differences.
> You are either mixing up concepts here completely, or you are
> quite inexperienced in timing issues.
  [ ... ]
>   tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
>   (tm_year-70)*31_536_000 + ((tm_year - 69)/4)*86400

Don't be an idiot. 2100 is not going to be a leap year.

Anyway, I'm perfectly aware that POSIX has documented the half-assed
behavior of some obsolete vendor libraries. This has no relevance to
the current discussion; I'm not using those libraries.

> To convert time_t into TAI, you need a leap second table, which
> practically no system on this planet has (systems operated by members
> of the tz mailing list excluded of course ;-).

False. Several vendors ship the tz library with the right time zones.

---Dan