* https://www.npr.org/2024/03/30/1241674216/climate-change-tim...
† T23:59:58Z would have skipped/suppressed :59 and gone to T00:00:00Z.
* https://www.npr.org/2024/03/30/1241674216/climate-change-tim...
† T23:59:58Z would have skipped/suppressed :59 and gone to T00:00:00Z.
I had to look it up: https://www.timeanddate.com/time/negative-leap-second.html . In proper words, the clock ("the one humanity agrees to use) would skip 23:59:59Z.
I wonder how much chaos a minute that only has 59 seconds would cause. Measurements would be off by that missing second (e.g. a pipeline delivering fuel at 60 liters/minute would surprisingly only have 59 liters in that minute..).
The FreeBSD folks test(ed?) their code for these things and it works:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course third-party userland code understanding what happens is another thing.
On unix this is what CLOCK_MONOTONIC is for; for one thing, the real-time clock can be reset at any time. Technically even CLOCK_MONOTONIC could jump forward. Real-time embedded systems either provide other timing APIs, or make additional guarantees about CLOCK_MONOTONIC's behavior.