[LEAPSECS] The Economist

[Markus Kuhn]

mike cook wrote on 2012-01-13 12:23 UTC:

> > http://www.economist.com/node/21542717

>

> You think that they could get it right....

> ITU-T TF.460-6 states :

> 2.2 A positive leap-second begins at 23h 59m 60s

> and not

> " causing clocks set to UTC to display 23:59:59 for two seconds instead 

> of one"


Just for the record:

Having been interviewed by the author (Tim Cross, Science Correspondent)
on the phone for about half an hour for the above Economist piece, I
certainly did explain to him both what the ITU/IERS notation for the
inserted leap second is (23:59:60), and what the Linux kernel PLL does
currently during a leap second with the "seconds since the epoch" count
provided to applications: namely jump back to 23:59:59 to repeat one
second, plus set a clock status flag that nobody ever reads in practice.

So he concluded (quite rightly) that 23:59:60 exists largely only on
paper, and the 23:59:59 repeat is was matters more in practice. He also
recalled that this non-monotonicity of a very popular implementation of
the leap second is what had concerned the engineers at Google, who are
now running internally a smoothed version of UTC on their NTP servers
without leap.

Will David L. Mills turn out to be the man who killed the leap second,
by widely implementing it in a rather brutal fashion? He writes of his
kernel time-keeping model in RFC 1589:

      If the value is TIME_INS, the kernel subtracts one
      second from the system time immediately following second 23:59:59
      and resets the clock status to TIME_OOP, in effect causing system
      time to repeat second 59.

He seemed aware of the problem that this might not be particularly nice
for applications, but failed to standardize and implement a much more
benign way of navigating through the leap second, suggesting instead
IMHO not very helpful hacks that might have been used to pass the
23:59:60 notation all the way to the application:

      Depending upon the system call implementation, the reported time
      during a leap second may repeat (with the TIME_OOP return code set
      to advertise that fact) or be monotonically adjusted until system
      time "catches up" to reported time. With the latter scheme the
      reported time will be correct before and shortly after the leap
      second (depending on the number of microtime() calls during the
      leap second), but freeze or slowly advance during the leap second
      itself. However, Most programs will probably use the ctime()
      library routine to convert from timeval (seconds, microseconds)
      format to tm format (seconds, minutes,...). If this routine is
      modified to use the ntp_gettime() system call and inspect the
      return code, it could simply report the leap second as second 60.

Markus

-- 
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain