You make it sound like time labels like "23:59:58Z" can perform actions (e.g. to skip or "suppress").
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..).
Nobody should be using an API like time(2) or clock_gettime(2)+CLOCK_REALTIME to measure event durations with sub-second precision or accuracy, especially when controlling mechanical equipment. And I'd be absolutely surprised if anybody was when controlling equipment, at least in a regulated industry.
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.
I feel like most of us don't know what we're actually doing when we do t2-t1 to get a duration. Feels like it'd be in a lot of places and a negative number is going to cause havoc. Even worse if it's an unsigned int and you roll over to some massive duration.
> I wonder how much chaos a minute that only has 59 seconds would cause.
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.