News: There will be another leap second on 23:59:60UTC 31-JUN-2012.
Nevertheless, I quitted supporting leap second on the time zone file at home last year on December 2011, which had been introduced for more than 12 years. Reason: I gain very little while I lose quite a lot by setting the system time based on TAI.
I think POSIX should have defined the timezone functions to handle leap seconds properly, by setting the TAI-based monotonically-increasing value to the local clock, and by correcting the difference between UTC and TAI with the timezone file. But POSIX doesn't. So TAI-based local time is not interchangeable. Most applications assume the value of time_t represents UTC without the leap seconds, which is not the case when the local clock is set based on TAI.
I suspect that many sysadmins are not really aware of the leap seconds, unfortunately, including those provide NTP services. I've experienced one of the upper-stratum NTP servers of my ISP did not synchronize on 1-JAN-2009, when the last leap second was added.
Very few language systems can explicitly handle leap seconds either. For example, I had to post a patch for Erlang for handling TAI. (Fixed on Erlang/OTP R13A and later.)
So you should be very careful on the de-synchronization of your machine's local clocks on June 30th or July 1st this year on 2012.
Useful links:
- The Future of Leap Seconds
- Leap Seconds by Markus Kuhn
- Communications ACM May 2011: The One-Second War
- The NTP Timescale and Leap Seconds
- D. J. Bernstein: UTC, TAI, and UNIX time
(Correction 8-JAN-2012: gmtime() was ambiguous. Corrected to time_t.)
