On Wed, Dec 28, 2016 at 10:33 PM, Zefram <[email protected]> wrote: > 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.
It specifically does not. It is a 100% uniform radix notion of time. It pre-supposed a very special notion for that phrase, as I describe below. > 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. That's implementation defined. Most wind up with it meaning the following second, but since leap seconds do not exist in POSIX, you cannot use that to infer what the proper time_t for the leap second should be. POSIX is only kinda sorta like UTC, and muddies the waters by saying seconds since 1970 GMT/UTC, when it really means 'Number of atomic seconds since 1972 + 365 * 2 * 86400 minus any positive leap seconds, plus any negative leap seconds, and the encoding of a leap second is undefined since we don't really acknowledge they exist.' They give examples with math that makes this interpretation crystal clear. Since leap seconds can't exist, you can't posit what would happen with any API giving you any answer that's required by the standards. Since it's implementation defined, the interpretation you give is allowed, but not required. Here "atomic seconds" means "number of PPS pulses generated by a perfectly ticking and functioning clock in operation since the epoch with the PPS produced at the top of every elapsed SI second" btw, which should go without saying, but since it's a pedantic discussions about standards must be said. POSIX does not have leap seconds at all. Any and all encoding and behavior around leap seconds is implementation defined. There are many good choices to make, and many bad ones, but they are outside the standard. > 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. Yes. As are a number of newly proposed CLOCK types. These both help and hurt the situation. They help in that they are the first attempts to try to break free from pure time_t requiring a uniform radix, but they likely don't go far enough since they aren't universally implemented, so they aren't universally used, and there's likely still bugs lurking in the current trial implementations to work out. > I have never seen a system that froze the clock. That would be most > unhelpful behaviour, making it impossible to recover true UTC. Older versions of Linux did just this. It was unhelpful enough that it got changed. Older unix system did do this but it got changed. Sadly, older systems are still deployed. Nobody today would think this is a good idea because of the systems that tried to freeze (or almost freeze) time during the leap second and the problems that were encountered by it. It's admittedly a stupid way to go, but it is allowed by the standard and has the nice property that monotonicity isn't broken, at the expense of a huge, short-term frequency error. Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
