4 ms·

Saying that something happened x-number of seconds (or minutes, hours, days or weeks) ago (or in the future) is simple: it’s giving that point in time a calenda

by foobar1962 2y ago

Saying that something happened x-number of seconds (or minutes, hours, days or weeks) ago (or in the future) is simple: it’s giving that point in time a calendar date that’s tricky.

wodenokoto 2y ago
Simple as long as your precision is at milliseconds and you don’t account for space travel. We can measure the difference in speed of time in a valley and a mountain (“just” take an atomic clock up a mountain and wait for a bit, bring it back to your lab where the other atomic clock is now out of sync)
GolDDranks 2y ago
But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.
miki123211 2y ago
> Saying that something happened x-number of [...]days or weeks) ago in the future) is simple It's not, actually. Does 2 days and 1 hour ago mean 48, 49 or 50 hours, if there was a daylight saving jump in the meantime? If it's 3PM and something is due to happen in 3 days and 2 hours, the user is going to assume and prepare for 5PM, but what if there's a daylight saving jump in the meantime? What happens to "in 3 days and 2 hours" if there's a leap second happening tomorrow that some systems know about and some don't? You rarely want to be thinking in terms of deltas when considering future events. If there is an event that you want to happen on jan 1, 2030 at 6 PM CET, there is no way to express that as a number of seconds between now and then, because you don't know whether the US government abolishes DST between now and 2030 or not. To reiterate this point, there is no way to make an accurate, constantly decreasing countdown of seconds to 6PM CET on jan 1, 2030, because nobody actually knows when that moment is going to happen yet.
- 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 :)

Saying that something happened x-number of seconds (or minutes, hours, days or weeks) ago (or in the future) is simple: it’s giving that point in time a calendar date that’s tricky.

wodenokoto 2y ago

Simple as long as your precision is at milliseconds and you don’t account for space travel. We can measure the difference in speed of time in a valley and a mountain (“just” take an atomic clock up a mountain and wait for a bit, bring it back to your lab where the other atomic clock is now out of sync)

GolDDranks 2y ago

But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.

miki123211 2y ago

> Saying that something happened x-number of [...]days or weeks) ago in the future) is simple It's not, actually. Does 2 days and 1 hour ago mean 48, 49 or 50 hours, if there was a daylight saving jump in the meantime? If it's 3PM and something is due to happen in 3 days and 2 hours, the user is going to assume and prepare for 5PM, but what if there's a daylight saving jump in the meantime? What happens to "in 3 days and 2 hours" if there's a leap second happening tomorrow that some systems know about and some don't? You rarely want to be thinking in terms of deltas when considering future events. If there is an event that you want to happen on jan 1, 2030 at 6 PM CET, there is no way to express that as a number of seconds between now and then, because you don't know whether the US government abolishes DST between now and 2030 or not. To reiterate this point, there is no way to make an accurate, constantly decreasing countdown of seconds to 6PM CET on jan 1, 2030, because nobody actually knows when that moment is going to happen yet.

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 :)