[klodolph]

Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two.

It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of just how deeply broken the status quo is?

[creshal]

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

[klodolph]

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing.

Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization.

I'm not even talking about bugs here—these are straight up design flaws.

[JdeBP]

There are actually two reasonable ways of handling leap seconds with gettimeofday(). The first, which is in actual use by a range of people, is to define that the kernel time is actually a TAI-10 count not a UTC count. Arthur David Olson's "right" timezone system does this. The second is to allow the microseconds count to go up to 2,000,000.

* http://www.madore.org/~david/computers/unix-leap-seconds.htm...

[klodolph]

I wonder how many clients handle that correctly. How many log files will have timestamps at "23:59:59.1500" instead of "23:59:60.500"? If you are going to break APIs you might as well make a new one instead.

And if you replace a simple API with one that requires distributing leap-second tables…

[creshal]

> And if you replace a simple API with one that requires distributing leap-second tables…

Not much worse than the distributed time zone tables we already need to update thrice a year. At least leap seconds aren't decided on by politicians.