4 ms·
"Lose information" is not a binary thing, nor is it equivalent to introducing wrong information. You don't expect (short)INT_MAX to suddenly give you 1337 just
by dataflow 3y ago
"Lose information" is not a binary thing, nor is it equivalent to introducing wrong information. You don't expect (short)INT_MAX to suddenly give you 1337 just because it "loses information". You still want to have (and do have) some useful properties & information to be preserved even after certain information loss, otherwise the implementation is buggy despite the information loss.
In this case, without leap seconds, you'd have still lost the precision, but you wouldn't have actually violated causality. Winding back during a leap second makes it so that a timestamp that's > 1 second later in real time still ends up being ordered as strictly before the earlier time. That's a bug, regardless of how you slice it.
Now this can be partially avoided by saturating the subtraction at the boundary rather than winding it back, and I'm not sure how many implementations do this. That seems better, but it's still surprising (and thus bug-prone) given the input and output representation otherwise appear to have sufficient precision.
- Dylan16807 3y agoI would say that Unix time doesn't violate causality, because it only does whole seconds and those whole seconds monotonically increase. You need to take extra care when bolting on fractional seconds. If converting things from one system to another means two very close events get the same timestamp? Eh, that can happen in many ways with many systems. That's not bugginess.