[ntp:questions] Google and leap seconds

Dave Hart hart at ntp.org
Tue Sep 20 14:40:54 UTC 2011

On Tue, Sep 20, 2011 at 12:20, Marco Marongiu <brontolinux at gmail.com> wrote:
> So I expect that OSs implementing the kernel discipline will go through
> 23:59:58 -> 23:59:59 -> 23:59:60 -> 00:00:00
> in case of a positive leap second, and
> 23:59:58 -> 00:00:00 -> 00:00:01
> in case of a negative one. This shouldn't have any negative effect on
> applications, unless they are designed to always expect second 00 to
> follow 59.

Your understanding is nearly perfect, assuming mine is perfect :)  The
rub here is that computers can't represent 23:59:60.  POSIX systems
keep time using time_t, defined as the number of seconds since
midnight Jan 1, 1970, in a fictional world without leap seconds.
Windows systems have the same problem, though their time counts 100s
of nanoseconds (tenths of a microsecond) since midnight Jan 1, 1601,
it also assumes no leap seconds.  Both timescales assume every day
since the epoch has lasted 86400 seconds exactly, so there is no
time-since-epoch counter value that maps to 23:59:60.

As I understand it, all POSIX ntpd will step backward one second to
accomplish a leap second insertion (we've yet to see a deletion).
Windows ntpd differs, and is closer to Google's smeared timescale in
spirit.  Leap seconds are inserted by Windows ntpd by slewing the
clock for 2 seconds, that is, the clock is run at half speed for two
seconds.  The Windows ntpd code doesn't yet accommodate leap second
deletions.  The advantage of this approach is time moves unceasingly
forward.  The disadvantage, particularly with such a short-lived
smear, is that interval timing that starts or ends during the special
two seconds will be inaccurate by up to a second.

Dave Hart

More information about the questions mailing list