Comment by eqvinox
2 days ago
UNIX timestamps are fully ignorant of leap seconds, i.e. pretends they don't exist. That means there can be physical seconds of time that cannot be referenced with a UNIX timestamp (when a leap second is inserted) as well as UNIX timestamps for seconds that don't exist (when a leap second is deleted).
It also means that if you subtract two timestamps, you might not get the actual time between them. Though this is also true of most ways of representing time (TAI being a notable exception).
The really annoying part is that "leap smearing" (where people decided to just mush the leap second across about day) has made CLOCK_MONOTONIC unclear in this regard, since some leap smearing approaches affect that as well. Which destroyed any assumption a developer could make about CLOCK_MONOTONIC, since you won't know if leap smearing is in use :(.
(And depending on the leap smearing implementation, it also smears CLOCK_TAI, jumps it to opposite polarity at the actual time of leap second, and then smears it again. The leap smearing people really made a mess of this.)
From a correctness perspective, the only good choice is to go all-in on TAI.
[Ed./P.S.:] "just ignore leap seconds" - that's going all-in on TAI. At this point it's probably easier to redefine UNIX timestamps as TAI based after 2035 ("abolishing leap seconds"), and introduce a new CLOCK_SOLAR_EARTH that accumulates leap seconds and can be used if/where necessary. The main issue is to create a proper delineation between the two clocks, which we just don't have at this point. Way too many systems where it's just not clear what they use.
And note that leap seconds are earth specific too. You'll have entirely different requirements on e.g. Mars.
> made CLOCK_MONOTONIC unclear in this regard
I don't understand what you mean. Doesn't smearing still mean the clock only goes forward? It's still steadily incrementing. The only difference is that a second is slightly longer/shorter than you expect, but you already have to account for that if you're doing the kind of physics experiment where it would matter.
2 replies →
I don't think I understand.. can you please dumb it down even more?
I'd figured that UNIX time just counts actual seconds and that leap seconds and similar calendar shenanigans would be a problem of mapping epoch to the correct date, so that if normally epoch X maps to date D then both epoch X and X+1 map to date D.
Am i to understand that leap seconds "stretch" a epoch unit ? so that some epoch second "lasted longer".
6 replies →
Well CLOCK_MONOTONIC was a bad name for anything that's supposed to do more than be... monotonic, with mild accuracy, so I'm not surprised things became unclear.
But it is just a basic system clock. Being the wrong speed by 15 parts per million shouldn't throw off your data collection. Lots of clocks are more inaccurate by accident.
After reading all that, maybe we should just have some bugs in our code and stop making up new things
"fully ignorant" might not have been the best wording there...
- clarification: "fully ignorant" from a human perspective, using dates and times. UNIX time lines up with those.