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