On Tue, Sep 20, 2011 at 12:20, Marco Marongiu <[email protected]> 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. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
