The Trouble with Leap Seconds, Part 2

"Don't you get it?! Don't you see?! You came back wrong."
—Spike, Buffy the Vampire Slayer

Like any other piece of software (and information generally), this comes with NO WARRANTY.

Countless errors have been coded into software because of this busted standard and because of methods that have attempted to compensate for bad design in the real world. One of the fundamental operations a computer is expected to perform is interval time measurement: "How many units of time elapsed between when A happened and when B happened?". No matter how people try to manage the adaptation, the fact is that the POSIX standard is going to require timestamps to jump around, either repeating the timestamp of the leap second or repeating the second just before the leap second and calling that repetition the leap. Regardless, POSIX timestamps cannot reliability be converted into a real-clock value because you can never be sure if you are inside the leap second or just on either side of it.

There are mechanisms that avoid this problem, but they require changes to the operating system configuration. You can't handle a leap second and still play by POSIX's rules. One of the more popular variant time scales is International Atomic Time (TAI), a French time scale designed in the 1950s. Somewhat ironically, the TAI scale works to account for POSIX's lack of accounting for leap seconds by ignoring leap seconds itself. The difference is that POSIX presupposes UTC, which requires leap seconds. The TAI time scale only ever increases, and always consistently, so leap seconds are never added and a TAI timestamp is never repeated. The TAI scale can always be converted to the more common UTC scale if you maintain a historical record of when UTC has had leap seconds added.

The historical record of leap seconds is well known. It's published by NIST and in other locations. You can even find it on Wikipedia or compressed into a table and distributed over DNS. Leap seconds are also merged into Arthur David Olson's tz library, now run by IANA after a frivolous lawsuit. It's pretty straight-forward to recompile your local time zone files. Typically the non-POSIX time zone files are found under the ".../right" directory where your zone files are kept. Even if you update your zone files, most of the programs on your computer will probably expect POSIX-compliant time zones, and this is where we run into trouble.

POSIX may not be accurate, but it's ubiquitous. If using the right time zone data were all it took, a lot more people would be doing it. Instead we find that most programs are designed around POSIX and are broken by design when it comes to time and date operations. One of these programs is NTP.

Next time: Epoch fail.

See also:
Part 1