3 ms·

No, bugs can come up without any subtraction. If an event was recorded as happening at 23:59:60.2, you need it to be sequenced strictly after 23:59:59.9. Windin

No, bugs can come up without any subtraction. If an event was recorded as happening at 23:59:60.2, you need it to be sequenced strictly after 23:59:59.9. Winding back the clock by 1 second makes it so you end up with the later event as having occurred at 23:59:59.2, violating causality. Even without sub-second precision the situation is still buggy, just not as bad - you end up with two simultaneous events when there weren't any in the original representation, which is itself quite surprising when the two look like they have the same precision.

heywhatupboys 3y ago
> you end up with the later event as having occurred at 23:59:59.1 Unix time is seconds since 1970... If you convert between time formats you MAY loose information. That has nothing to do with unix time.
- 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 ago
    I 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.
- zokier 3y ago
  > Unix time is seconds since 1970... This is unfortunately common misconception. Unix time in reality is seconds since epoch minus the number of leap seconds
  - heywhatupboys 3y ago
    no, it just doesn't care about "leap seconds". I it just a guy hwo started counting at 1970
    - SAI_Peregrinus 3y ago
      UNIX time double-counts leap seconds. UTC: 58, 59, 60, 00, 01 UNIX: 58, 59, 00, 00, 01

heywhatupboys 3y ago

> you end up with the later event as having occurred at 23:59:59.1 Unix time is seconds since 1970... If you convert between time formats you MAY loose information. That has nothing to do with unix time.

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 ago
  I 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.
zokier 3y ago
> Unix time is seconds since 1970... This is unfortunately common misconception. Unix time in reality is seconds since epoch minus the number of leap seconds
- heywhatupboys 3y ago
  no, it just doesn't care about "leap seconds". I it just a guy hwo started counting at 1970
  - SAI_Peregrinus 3y ago
    UNIX time double-counts leap seconds. UTC: 58, 59, 60, 00, 01 UNIX: 58, 59, 00, 00, 01