Re: [LEAPSECS] What problems do leap seconds *really* create?

From: Markus Kuhn <>
Date: Thu, 30 Jan 2003 12:14:39 +0000

John Cowan wrote on 2003-01-29 20:05 UTC:
> I was a little too clipped. If you know all the leap seconds, you can
> convert a Unix-style timestamp to UTC reliably;

Sorry, that's not correct. It's merely a common missunderstanding of the
definition of POSIX timestamps. There exists already a perfectly simple
algorithmic leap-second-table-free mapping between Unix-style timestamps
and UTC, specified formally in

  ISO/IEC 9945-1:1996, Section

Unix timestamps have always been meant to be an encoding of a
best-effort approximation of UTC. They have always counted the non-leap
seconds since 1970-01-01. The only minor problem is that the value
23:59:60 cannot be represented uniquely in the time_t encoding, but that
is in practice elegantly circumvented by changing the length of the Unix
second near a UTC leap second by less than a percent (UTC smoothing,
something which I suggest should be standardized formally for Unix-style
timestamps to improve interoperability of timestamps near leap seconds).
The older POSIX.1:1996 interpretation above could be quoted as implying
that time_t has to jump back during a leap second because the formula
provided leads to the same numeric value for 23:59:60 and 00:00:00 the
next day (unfortunately, that is still what the Linux NTP kernel support
does today). The POSIX.1:2001 revision softened the definition in order
to include the option of UTC smoothing into what it allows, making it
possible to use a more graceful leap second representation in time_t,
such as for example my UTS proposal.


Markus Kuhn, Computer Lab, Univ of Cambridge, GB | __oo_O..O_oo__
Received on Thu Jan 30 2003 - 04:14:47 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT