4 ms·

I believe if you're using epoch timestamps you already have leap seconds bugs. I don't think they increment/decrement when the leap second happens.

morelisp 3y ago
If you're using epoch timestamps to represent time you don't have leap second bugs. Each Unix timestamp corresponds to one unique point in time which also has some representation in civil time. If you're subtracting Unix timestamps to get durations you may have bugs, but those bugs might align better to your user's expectations anyway.
- dataflow 3y ago
  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
- wongarsu 3y ago
  > Each Unix timestamp corresponds to one unique point in time That depends. 30th June 2015 23:59:59 has the timestamp 1435708799. 1st July 2015 00:00:00 has the timestamp 1435708800. But what about the leap second that happened between those two seconds? I think most people would claim it also has timestamp 1435708799. but then "Each Unix timestamp corresponds to one unique point in time" isn't true, because 1435708799 now corresponds to two different points in time (30th June 2015 23:59:59 and 30th June 2015 23:59:60). Saying there is a unique mapping from unix timestamp to time would only be true if you either say that 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) or if you smear time.
  - jodrellblank 3y ago
    It still wouldn't be true because there are points in time smaller than a second.
    - morelisp 3y ago
      No, I didn't say it was a bijective mapping. (Although with smearing, it still can be.)
  - morelisp 3y ago
    > 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) https://go.dev/play/p/I8GcKBoAVXi https://go.dev/play/p/I8GcKBoAVXi
  - bobbylarrybobby 3y ago
    Well, all time stamps are rounded or floored to the nearest second (or millisecond, or micro, or...) because you only have a finite amount of space to store them — you always have infinitely many time stamps mapping to each Unix second. This means you can just adjust the mapping around the leap second. A naive implementation might have those two real-life seconds tick twice as fast to take only one Unix second. Or you could have the whole day’s seconds tick 86401/86400 times as fast, etc. In terms of the mapping from continuous time to discrete time, this is just as fine as the non-leap-second case.
- zokier 3y ago
  > Each Unix timestamp corresponds to one unique point in time which also has some representation in civil time This is plain false. For example 1435708799 corresponds to both 2015-06-30T23:59:59Z and 2015-06-30T23:59:60Z
  - morelisp 3y ago
    No, your misdesigned ntpd resets your clock to 1435708799 at 2015-06-30T23:59:60Z. I have yet to see a convincing argument that smearing and freezing are not compatible with POSIX's definitions of time.
    - zokier 3y ago
      its kernel that does the leap second handling, ntpd just informs it of upcoming leaps https://elixir.bootlin.com/linux/v6.4.1/source/kernel/time/ntp.c#L406 https://elixir.bootlin.com/linux/v6.4.1/source/kernel/time/n... sure leap smearing could be considered compatible with posix in the sense that posix does afaik not require any level of accuracy from clocks, so even something silly like xkcd 2266 could be considered posix compatible https://xkcd.com/2266/ https://xkcd.com/2266/

morelisp 3y ago

If you're using epoch timestamps to represent time you don't have leap second bugs. Each Unix timestamp corresponds to one unique point in time which also has some representation in civil time. If you're subtracting Unix timestamps to get durations you may have bugs, but those bugs might align better to your user's expectations anyway.

dataflow 3y ago
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
wongarsu 3y ago
> Each Unix timestamp corresponds to one unique point in time That depends. 30th June 2015 23:59:59 has the timestamp 1435708799. 1st July 2015 00:00:00 has the timestamp 1435708800. But what about the leap second that happened between those two seconds? I think most people would claim it also has timestamp 1435708799. but then "Each Unix timestamp corresponds to one unique point in time" isn't true, because 1435708799 now corresponds to two different points in time (30th June 2015 23:59:59 and 30th June 2015 23:59:60). Saying there is a unique mapping from unix timestamp to time would only be true if you either say that 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) or if you smear time.
- jodrellblank 3y ago
  It still wouldn't be true because there are points in time smaller than a second.
  - morelisp 3y ago
    No, I didn't say it was a bijective mapping. (Although with smearing, it still can be.)
- morelisp 3y ago
  > 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) https://go.dev/play/p/I8GcKBoAVXi https://go.dev/play/p/I8GcKBoAVXi
- bobbylarrybobby 3y ago
  Well, all time stamps are rounded or floored to the nearest second (or millisecond, or micro, or...) because you only have a finite amount of space to store them — you always have infinitely many time stamps mapping to each Unix second. This means you can just adjust the mapping around the leap second. A naive implementation might have those two real-life seconds tick twice as fast to take only one Unix second. Or you could have the whole day’s seconds tick 86401/86400 times as fast, etc. In terms of the mapping from continuous time to discrete time, this is just as fine as the non-leap-second case.
zokier 3y ago
> Each Unix timestamp corresponds to one unique point in time which also has some representation in civil time This is plain false. For example 1435708799 corresponds to both 2015-06-30T23:59:59Z and 2015-06-30T23:59:60Z
- morelisp 3y ago
  No, your misdesigned ntpd resets your clock to 1435708799 at 2015-06-30T23:59:60Z. I have yet to see a convincing argument that smearing and freezing are not compatible with POSIX's definitions of time.
  - zokier 3y ago
    its kernel that does the leap second handling, ntpd just informs it of upcoming leaps https://elixir.bootlin.com/linux/v6.4.1/source/kernel/time/ntp.c#L406 https://elixir.bootlin.com/linux/v6.4.1/source/kernel/time/n... sure leap smearing could be considered compatible with posix in the sense that posix does afaik not require any level of accuracy from clocks, so even something silly like xkcd 2266 could be considered posix compatible https://xkcd.com/2266/ https://xkcd.com/2266/