D. J. Bernstein
djb at cr.yp.to
Sun May 31 03:44:55 UTC 1998
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.
More information about the tz