[LEAPSECS] Rubber seconds, UTC-SLS
Markus.Kuhn at cl.cam.ac.uk
Sun Jan 29 11:53:53 EST 2012
=?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
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
for the difference between UTC-SLS and Google's alternative, and
why UTC-SLS is the more robust long-term solution IMHO.
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
More information about the LEAPSECS