Yes I would assume that the NTP daemon would handle a leap second arrival with guarantees of (1) gradual application over a longer period and (2) never moving the clock backwards, only slowing it a little.

I wonder if all NTP implementations don't follow those guarantees?

Oh and another app that hates clock jumps used to be sshd; it would just bail out and drop all connections. We found that out while chasing ANOTHER bug in SunOS on a T4: they didn't have it mutexed right so it possible to read its RTC register while it was in the middle of getting updated so the client would read a garbage time. We chased NTP for a week before realizing it was the kernel.

The insanity is that both NTP and unix timestamps need to be wound back during a leap second, as well as computer hardware clocks. If we just had monotonic clocks everwhere and adjusted for leap seconds in presentation then we wouldn't have many of the associated problems.

It's not like we wound back by 24 hours on leap days, that would be insanity. So in addition of leapseconds being a rare problem, it's also handled in a uniquely bad way.

WDYM? Leap seconds are a 61st second, hitting 60 before 00 next minute. https://nrc.canada.ca/en/certifications-evaluations-standard...

This makes sense for timestamps in traditional logs. You don't have to second guess the order of things, especially across multiple systems or services.

I meant unix and NTP times, which are supposedly just monotonic numbers marching forward (except for leap seconds), not the UTC representation over abstract time.

I know we just get a 60th second in a minute. What unix and NTP timestamps do (or originally did) was repeating a second. Then we got other hacks to keep monotonicity, like smearing. Not without tradeoffs.

Thanks for explaining! It's indeed crazy that "this is still a thing".

(I regret I did not put in the research prior to answering to your comment: https://www.meinbergglobal.com/english/info/leap-second.htm#... )