=?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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
