> It's frustrating that programmers want to redefine civil time just because it is "hard".
Yes. Problems with delay time going negative usually come from not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is usually just the time since system startup. It comes from QNX (which, being hard real time, had to deal with this first), made it into the POSIX spec around 1996, and is now available on all major OSs. But there's still software that uses time of day where CLOCK_MONOTINIC is needed.
Then there's the smoothing approach. This document described Facebook's smoothing approach, which has a different smoothing period than Google uses.
* Facebook/Meta: "We smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content." This is puzzling. What does the time zone package have to do with UTC?
* Google: 24-hour linear smear from noon to noon UTC.[1]
* AWS: Follows Google.
* US power grid: Starts at midnight UTC and takes a few hours while all the rotating machinery takes 60 extra turns to catch up.
> What does the time zone package have to do with UTC?
The IANA TZ database includes information about leap seconds, and even supports the concept of "right" time zones in which the leap seconds are counted in the Unix timestamps. (Which violates the unix spec, and may cause problems with code that assumes it can do path like `1 day= 24*60*60`, but on the other hand, things like DST already make that unsafe).
It is mostly likely simply the case that they are using the leap second data from the time-zone database as a convenient source of this data.
Yes. Problems with delay time going negative usually come from not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is usually just the time since system startup. It comes from QNX (which, being hard real time, had to deal with this first), made it into the POSIX spec around 1996, and is now available on all major OSs. But there's still software that uses time of day where CLOCK_MONOTINIC is needed.
Then there's the smoothing approach. This document described Facebook's smoothing approach, which has a different smoothing period than Google uses.
* Facebook/Meta: "We smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content." This is puzzling. What does the time zone package have to do with UTC?
* Google: 24-hour linear smear from noon to noon UTC.[1]
* AWS: Follows Google.
* US power grid: Starts at midnight UTC and takes a few hours while all the rotating machinery takes 60 extra turns to catch up.
Not sure what telecom is doing.
[1] https://developers.google.com/time/smear