Warner Losh wrote: >Except that it does advance... It plays the second twice, once with >the pending leap set, and once with it cleared I though.
In practice the flags are not that well behaved. I see the second played twice, but the flag change is not synchronised with the jump of the scalar time value. In the logs I have, the flag changed about halfway through the second iteration of the second. So empirically, the two seconds cannot be distinguished purely by means of the packet on the wire. This isn't a big problem for NTP. By design it's robust against occasional lost packets, so just dropping the ambiguous packets is an adequate workaround. >POSIX is silent on leap seconds. Not if one takes the definition of "seconds since the epoch" seriously. During a leap second tm_sec would be 60. The defining expression is perfectly well defined in these circumstances, and the definition doesn't say that it *doesn't* apply during a leap second. (The hedging clauses are all about not requiring the clock to be accurate; they don't hedge about what the clock reading means.) So ostensibly the leap second is represented by a time_t value indistinguishable from that for the *following* second. Of course, in practice this implication gets ignored by NTP-disciplined kernel clocks. They tend to follow NTP behaviour for the scalar value (though older Linux versions used to repeat an unaligned second, not quite matching the NTP behaviour). Fortunately, the flags supplied by adjtimex(2) *are* sufficient to disambiguate, regardless of which second gets repeated in the time_t. I have never seen a system that froze the clock. That would be most unhelpful behaviour, making it impossible to recover true UTC. -zefram _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs