The leap second bug

Posted Jul 2, 2012 17:22 UTC (Mon) by fest3er (guest, #60379)
Parent article: The leap second bug

Good Lord, I'm glad computers didn't exist in the 1700s when 2½ weeks were dropped; surely the universe would've imploded from the loss of all that time.

I don't understand the difficulty. Leap seconds, minutes, hours, days, years are simply adjustments to our perception of 'now' and should be handled in the same way as all other date conversion problems. Elapsed time is contiguous and constant*; our interpretation of elapsed time into 'when' is discontiguous where adjustments are concerned.

* Fairly constant in our gravity well. Time passes at a slightly different pace up in orbit.

The leap second bug

Posted Jul 3, 2012 1:53 UTC (Tue) by kevinm (guest, #69913) [Link]

This is a great sentiment, but unfortunately POSIX doesn't agree, so we are stuck with having to munge time for leap seconds.

(POSIX time_t isn't the number of seconds since 01-JAN-1970 00:00 UTC - it's the number of whole days since then multiplied by 86400 plus the number of seconds since the most recent midnight UTC).

The leap second bug

Posted Jul 3, 2012 9:38 UTC (Tue) by Tobu (subscriber, #24111) [Link]

If you want to break convention and use TAI64 timestamps rather than POSIX timestamps (which are ambiguous when a leap second is inserted), you can use djb's libtai. Of course, you won't be protected from leap second bugs in the kernel or glibc. And these can only be used internally, but you should already be using RFC 3339 dates for interoperability anyway. Finally you need to maintain your own leap second table without the help of NTP. Or for many uses when the timestamps won't leave your process, you can use clock_gettime with CLOCK_MONOTONIC.