[LEAPSECS] Rubber seconds, UTC-SLS

[Markus Kuhn]

=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= wrote on 2012-01-25 22:54 UTC:

> How should public NTP servers behave during the leap second period

> if there's no agreed upon "rubberization scheme"?


The detailed UTC-SLS rubber-second proposal at

  http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
  http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/draft-kuhn-leapsecond-00.txt

gives a clear answer, namely:

  - NTP servers do on the wire *exactly* what they do at the moment, namely
    broadcasting UTC (in its current form), using the POSIX
    "seconds-since-the-epoch" encoding of yyyy-mm-dd hh:mm:ss.
    (During a leap second, an NTP server best does not answer
    any questions; the protocol and implemenation is perfectly able to
    withstand 1000 ms long outages once every couple of years.)

  - Operating systems and their NTP client modules are informed by NTP servers
    when leap seconds are, and thy implement (in a precisely standardized fashion)
    rubber seconds shortly before the leap second, and they communicate these
    leap seconds via gettimeofday() & friends to all normal applications
    (other than those concerned with leap seconds or TAI, e.g. NTP servers).
    Specialist applications concerned with leap seconds or TAI use specialist
    library calls to get the whole story.

In particular, read

  http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/#google

for the difference between UTC-SLS and Google's alternative, and
why UTC-SLS is the more robust long-term solution IMHO.

Markus

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