3 ms·

You ignored the last part of their comment. All your examples are things they did say are hard. Also natural events are the other way around, we can know they

by Izkata 2y ago

You ignored the last part of their comment. All your examples are things they did say are hard. Also natural events are the other way around, we can know they're X in the future but not the exact calendar date/time.

PaulDavisThe1st 2y ago
No. The problems begin because GP included the idea of saying "N <calendar units> in the future". If the definition of a future time was limited to hours, minutes and/or seconds, then it would be true that the only hard part is answering "what calendrical time and date is that?" But if you can say "1 day in the future", you're already slamming into problems before even getting to ask that question.
- AnthonyMouse 2y ago
  The real problem here is that people keep trying to screw up the simple thing. If you want to know the timestamp of "two days from now" then you need to know all kinds of things like what time zone you're talking about and if there are any leap seconds etc. That would tell you if "two days from now" is in 172800 seconds or 172801 seconds or 169201 or 176400 etc. But the seconds-counting thing should be doing absolutely nothing other than counting seconds and doing otherwise is crazy. The conversion from that into calendar dates and so on is for a separate library which is aware of all these contextual things that allow it to do the conversion. What we do not need and should not have is for the seconds counting thing to contain two identical timestamps that refer to two independent points in time. It should just count seconds.
  - growse 2y ago
    Agree, but people often miss that there's two different use cases here, with different requirements. "2 days from now" could either mean "after 2*86400 seconds have ticked" or it could mean "when the wall clock looks like it does now, after 2 sunset events". These are not the same thing. The intent of the thing demanding a future event matters. So you can have the right software abstractions all you like and people will still use the wrong thing. The problem is that programmers are human, and humans don't reason in monotonic counters :)
    - PaulDavisThe1st 2y ago
      One might also recall the late Gregory Bateson's reiteration that "number and quantity are not the same thing - you can have 5 oranges but you can never have 5 gallons of water" [0] Seconds are numbers; calendrical units are quantities. [0] Bateson was, in some ways, anticipating the divide between the digital and analog worlds.
    - AnthonyMouse 2y ago
      > "2 days from now" could either mean "after 2*86400 seconds have ticked" or it could mean "when the wall clock looks like it does now, after 2 sunset events". These are not the same thing. Which is why you need some means to specify which one you want from the library that converts from the monotonic counter to calendar dates. Anyone who tries to address the distinction by molesting the monotonic counter is doing it wrong.

by Izkata 2y ago

PaulDavisThe1st 2y ago

No. The problems begin because GP included the idea of saying "N <calendar units> in the future". If the definition of a future time was limited to hours, minutes and/or seconds, then it would be true that the only hard part is answering "what calendrical time and date is that?" But if you can say "1 day in the future", you're already slamming into problems before even getting to ask that question.

AnthonyMouse 2y ago
The real problem here is that people keep trying to screw up the simple thing. If you want to know the timestamp of "two days from now" then you need to know all kinds of things like what time zone you're talking about and if there are any leap seconds etc. That would tell you if "two days from now" is in 172800 seconds or 172801 seconds or 169201 or 176400 etc. But the seconds-counting thing should be doing absolutely nothing other than counting seconds and doing otherwise is crazy. The conversion from that into calendar dates and so on is for a separate library which is aware of all these contextual things that allow it to do the conversion. What we do not need and should not have is for the seconds counting thing to contain two identical timestamps that refer to two independent points in time. It should just count seconds.
- growse 2y ago
  Agree, but people often miss that there's two different use cases here, with different requirements. "2 days from now" could either mean "after 2*86400 seconds have ticked" or it could mean "when the wall clock looks like it does now, after 2 sunset events". These are not the same thing. The intent of the thing demanding a future event matters. So you can have the right software abstractions all you like and people will still use the wrong thing. The problem is that programmers are human, and humans don't reason in monotonic counters :)
  - PaulDavisThe1st 2y ago
    One might also recall the late Gregory Bateson's reiteration that "number and quantity are not the same thing - you can have 5 oranges but you can never have 5 gallons of water" [0] Seconds are numbers; calendrical units are quantities. [0] Bateson was, in some ways, anticipating the divide between the digital and analog worlds.
  - AnthonyMouse 2y ago
    > "2 days from now" could either mean "after 2*86400 seconds have ticked" or it could mean "when the wall clock looks like it does now, after 2 sunset events". These are not the same thing. Which is why you need some means to specify which one you want from the library that converts from the monotonic counter to calendar dates. Anyone who tries to address the distinction by molesting the monotonic counter is doing it wrong.