ntpd will step backward if error stays above a configurable threshold for a configurable period of time. We saw it happen after the recent leap second. 1 second exceeds the default step threshold of 128 ms. With Linux limiting the slew rate to 500 ppm, gradual correction would have taken 2000 seconds, and by default nptd steps after 900 seconds.

> ntpd guarantees (under the default settings now [...]) that the clock will never go backwards.

Can you elaborate on what changed? I just downloaded the latest reference implementation, and the man page still seems to indicate that the default behavior is to step when error > 128ms for a prolonged period.

There is no such guarantee when using CLOCK_REALTIME. If you need this guarantee, use the monotonic clock. I've had issues with graphics engines written naively assuming nobody would change CLOCK_REALTIME. It's a bad assumption because many embedded systems well not use ntp and will instead rely on a user to set the clock. It may go backwards if the user sets it backwards. It may even do so while your software is doing something like presenting the user with a UI to set the time.

With Linux/NTP there was two times 23:59:59 UTC not long ago: https://access.redhat.com/articles/15145

The clocks go back an hour every year here in (most of) Australia. Every year, on a specific date 1am-2am happens twice.

Do you mean daylight saving time? The time zone changes, but Unix time is UTC so it's unaffected.