4 ms·

> We know that some character must be smaller than 9, for example, we cannot have more than 59 seconds and never 60 seconds, in the time stamp string. This is

by zokier 3y ago

> We know that some character must be smaller than 9, for example, we cannot have more than 59 seconds and never 60 seconds, in the time stamp string. This is how you get leap seconds bugs?

dataflow 3y ago
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
  - 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/
paulddraper 3y ago
> we want to convert them to an integer presenting the number of seconds since the Unix epoch. The Unix epoch is January 1st 1970. UNIX time ignores leap seconds. I.e. it's the number of seconds ignoring leap seconds since 1970.
- MobiusHorizons 3y ago
  Sure, but he’s not parsing Unix timestamps. He’s parsing time in the format %Y%m%d%H%M%S, which would have leap seconds on most systems
  - paulddraper 3y ago
    He's parsing them into UNIX timestamps. And apparently these strings don't have second 60. Works for me.
- dataflow 3y ago
  > UNIX time ignores leap seconds. Side note but I always found this phrasing to be incredibly confusing (hence the need for the "i.e."...); it's the exact opposite of what I would think it means to "ignore" leap seconds. Ignoring something means you don't change your behavior when that something happens. But when leap seconds happen, the epoch timestamp halts its counting. That's not ignoring leap seconds -- that's actively countering the leap seconds!
  - paulddraper 3y ago
    Ignores = does nothing Normally, UNIX time goes up by one each second. Unless, it's a leap second, in which case UNIX time does nothing.
    - dataflow 3y ago
      Halting the advancement that would've ordinarily happened is not "ignoring it", it's doing something to actively counter it. That "something" ends up canceling the previous trajectory to evaluate to "nothing", but that doesn't happen through ignorance - it required a countering action. Example: You're driving your car when pedestrians appear in front of you. What does "ignoring" them constitute? Stopping the car, or running into them at the previous speed?
worewood 3y ago
Reminds me of that post about things programmers always get wrong about dates [1]. [1]: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208
ryandrake 3y ago
Yea, my eye twitched when I read that and I said to myself “so, who’s gonna tell him?” Glad to see this is the top comment. This is why we should not roll our own anything.
- habitue 3y ago
  > This is why we should not roll our own anything. This seems like a major overcorrection. It's equivalent to saying "you can't know anything" "no one is qualified to do anything" You really have to consider the downsides. In cryptography, "don't roll you own crypto" is the maxim because the downside is pretty bad. Make sure you're an expert before writing crypto. What's the downside to mis-parsing leap seconds? Maybe a 500 on a super rare request? Then they patch it and it's fine? Most computers are off by more than 1 second anyway. I think this mindset comes from developers looking into some field and realizing it's super deep ("Did you know there are missing dates in the gregorian calendar if you go back hundreds of years? Your time library is incorrect if it doesn't handle these cases!"). And sure, most things aren't completely correct, but you have to consider what the downside is to being slightly wrong. Maybe it'll be wrong in cases that will never actually happen in practice.
- simlevesque 3y ago
  > This is why we should not roll our own anything. How is anything going to be made then ? Also, the author isn't just anybody and has created stuff that you've most likely interacted with. If almost nobody should "roll his own", he's one of those who should.
notfed 3y ago
Can you elaborate? How does this lead to a leap second bug? Would a string really say "60" as the number of seconds, somehow, due to leap seconds?
- layer8 3y ago
  Yes: http://www.niceties.com/leapsec.html http://www.niceties.com/leapsec.html See also: http://leapsecond.com/notes/leap-watch.htm http://leapsecond.com/notes/leap-watch.htm

by zokier 3y ago

> We know that some character must be smaller than 9, for example, we cannot have more than 59 seconds and never 60 seconds, in the time stamp string. This is how you get leap seconds bugs?

dataflow 3y ago

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
- 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/

paulddraper 3y ago

> we want to convert them to an integer presenting the number of seconds since the Unix epoch. The Unix epoch is January 1st 1970. UNIX time ignores leap seconds. I.e. it's the number of seconds ignoring leap seconds since 1970.

MobiusHorizons 3y ago
Sure, but he’s not parsing Unix timestamps. He’s parsing time in the format %Y%m%d%H%M%S, which would have leap seconds on most systems
- paulddraper 3y ago
  He's parsing them into UNIX timestamps. And apparently these strings don't have second 60. Works for me.
dataflow 3y ago
> UNIX time ignores leap seconds. Side note but I always found this phrasing to be incredibly confusing (hence the need for the "i.e."...); it's the exact opposite of what I would think it means to "ignore" leap seconds. Ignoring something means you don't change your behavior when that something happens. But when leap seconds happen, the epoch timestamp halts its counting. That's not ignoring leap seconds -- that's actively countering the leap seconds!
- paulddraper 3y ago
  Ignores = does nothing Normally, UNIX time goes up by one each second. Unless, it's a leap second, in which case UNIX time does nothing.
  - dataflow 3y ago
    Halting the advancement that would've ordinarily happened is not "ignoring it", it's doing something to actively counter it. That "something" ends up canceling the previous trajectory to evaluate to "nothing", but that doesn't happen through ignorance - it required a countering action. Example: You're driving your car when pedestrians appear in front of you. What does "ignoring" them constitute? Stopping the car, or running into them at the previous speed?

worewood 3y ago

Reminds me of that post about things programmers always get wrong about dates [1]. [1]: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208

ryandrake 3y ago

Yea, my eye twitched when I read that and I said to myself “so, who’s gonna tell him?” Glad to see this is the top comment. This is why we should not roll our own anything.

habitue 3y ago
> This is why we should not roll our own anything. This seems like a major overcorrection. It's equivalent to saying "you can't know anything" "no one is qualified to do anything" You really have to consider the downsides. In cryptography, "don't roll you own crypto" is the maxim because the downside is pretty bad. Make sure you're an expert before writing crypto. What's the downside to mis-parsing leap seconds? Maybe a 500 on a super rare request? Then they patch it and it's fine? Most computers are off by more than 1 second anyway. I think this mindset comes from developers looking into some field and realizing it's super deep ("Did you know there are missing dates in the gregorian calendar if you go back hundreds of years? Your time library is incorrect if it doesn't handle these cases!"). And sure, most things aren't completely correct, but you have to consider what the downside is to being slightly wrong. Maybe it'll be wrong in cases that will never actually happen in practice.
simlevesque 3y ago
> This is why we should not roll our own anything. How is anything going to be made then ? Also, the author isn't just anybody and has created stuff that you've most likely interacted with. If almost nobody should "roll his own", he's one of those who should.

notfed 3y ago

Can you elaborate? How does this lead to a leap second bug? Would a string really say "60" as the number of seconds, somehow, due to leap seconds?

layer8 3y ago
Yes: http://www.niceties.com/leapsec.html http://www.niceties.com/leapsec.html See also: http://leapsecond.com/notes/leap-watch.htm http://leapsecond.com/notes/leap-watch.htm