3 ms·

> Why not epoch? Which epoch? There are many, it’ll change depending on your system. Also what unit? Seconds, milliseconds, nanoseconds. That will also change

> Why not epoch? Which epoch? There are many, it’ll change depending on your system. Also what unit? Seconds, milliseconds, nanoseconds. That will also change depending on your system. If someone is saying store UTC then they 100% mean store it in ISO8601 or an equivalent standard. > Why not offset? ISO8601 is a good standard. Because the offset for timezones change (as is explained in the article). If you just store an offset, then you have no way of knowing which timezone the user meant, and thus you can’t compensate for changes in the timezone definition (again, the primary thrust of the article). > In my opinion there are only two ways to store timestamps that are actually correct: epoch, or iso8601. Everything else will eventually lead to data corruption. The entire article is describing why this approach isn’t enough.

knorker 5y ago
> Which epoch? There are many, it’ll change depending on your system. That's missing the point. That's like arguing if DD/MM/YYYY or YYYY-MM-DD is the format. That's not where the hard part of programming with time is. > Also what unit? Seconds, milliseconds, nanoseconds. Just implementation details that don't affect anything. > If you just store an offset, then you have no way of knowing which timezone the user meant True. But it depends what you mean. If you scheduled a world wide meeting then you probably want offset. If the meeting is defined as "five minutes past noon in New York" then UTC and offset be damned. So it depends. A cross-timezone event needs to live somewhere. It can live as offset from UTC, or physical location, but it all depends what the intention is. > The entire article is describing why this approach isn’t enough. Like I said, you still need to be careful.
- avianlyric 5y ago
  > That's missing the point. That's like arguing if DD/MM/YYYY or YYYY-MM-DD is the format. Not really. We’re talking about unambiguous storage and transmission of date time. Epoch has the big problem that it only makes sense on the system that generated. By itself an epoch doesn’t contain enough data to decode it correctly, and be certain your interpretation is correct. With a date-time format like ISO 8601 you need no further information to decode the time correctly to a human relevant time reference. Even if you don’t know the exact format used, it’s usually possible to figure it out if your have enough examples, the same isn’t true of epoch. > Just implementation details that don't affect anything Hahaha, oh god. Those entire article and discussion is all about implementation detail of date time storage, and why it does effect things. For the epoch unit it matters is your want two systems to communicate with each other. It’s a total pain in the arse working with epoch because every platform and language handles epoch times subtly different. Units in particular and really mess you up, especially when multiple systems have different levels of precision. > True. But it depends what you mean. If you scheduled a world wide meeting then you probably want offset. If the meeting is defined as "five minutes past noon in New York" then UTC and offset be damned. Every meeting involving humans involves a physical location (the humans have to at least physically occupy the space in front of cameras) the same . So you need pick somewhere, the host location would be the obvious choice. > Like I said, you still need to be careful. Great, so your contribution to this topic is to state the obvious, then say be careful, edge cases exist. How does that add to a conversation about an article that’s actually exploring those edge cases?
  - knorker 5y ago
    > Hahaha, oh god. Those entire article and discussion is all about implementation detail of date time storage, and why it does effect things. Please keep a more respectful tone. I disagree. It's talking about much higher level things, things which are both more interesting and harder to solve. > Every meeting involving humans involves a physical location Yes, but not necessarily one predetermined one. > So you need pick somewhere It's one way to do it, but it's not the only way. E.g. UTC is not a place. As I understand it the US military is heavy on Zulu. > Great, so your contribution to this topic is to state the obvious, then say be careful, edge cases exist. I'm sorry you don't understand my points about what is hard about time programming.
    - avianlyric 5y ago
      > I'm sorry you don't understand my points about what is hard about time programming. Could you try making your points a littler clearer and easier to understand? Voting strongly suggests I’m not the only one unable to understand you.

knorker 5y ago

> Which epoch? There are many, it’ll change depending on your system. That's missing the point. That's like arguing if DD/MM/YYYY or YYYY-MM-DD is the format. That's not where the hard part of programming with time is. > Also what unit? Seconds, milliseconds, nanoseconds. Just implementation details that don't affect anything. > If you just store an offset, then you have no way of knowing which timezone the user meant True. But it depends what you mean. If you scheduled a world wide meeting then you probably want offset. If the meeting is defined as "five minutes past noon in New York" then UTC and offset be damned. So it depends. A cross-timezone event needs to live somewhere. It can live as offset from UTC, or physical location, but it all depends what the intention is. > The entire article is describing why this approach isn’t enough. Like I said, you still need to be careful.

avianlyric 5y ago
> That's missing the point. That's like arguing if DD/MM/YYYY or YYYY-MM-DD is the format. Not really. We’re talking about unambiguous storage and transmission of date time. Epoch has the big problem that it only makes sense on the system that generated. By itself an epoch doesn’t contain enough data to decode it correctly, and be certain your interpretation is correct. With a date-time format like ISO 8601 you need no further information to decode the time correctly to a human relevant time reference. Even if you don’t know the exact format used, it’s usually possible to figure it out if your have enough examples, the same isn’t true of epoch. > Just implementation details that don't affect anything Hahaha, oh god. Those entire article and discussion is all about implementation detail of date time storage, and why it does effect things. For the epoch unit it matters is your want two systems to communicate with each other. It’s a total pain in the arse working with epoch because every platform and language handles epoch times subtly different. Units in particular and really mess you up, especially when multiple systems have different levels of precision. > True. But it depends what you mean. If you scheduled a world wide meeting then you probably want offset. If the meeting is defined as "five minutes past noon in New York" then UTC and offset be damned. Every meeting involving humans involves a physical location (the humans have to at least physically occupy the space in front of cameras) the same . So you need pick somewhere, the host location would be the obvious choice. > Like I said, you still need to be careful. Great, so your contribution to this topic is to state the obvious, then say be careful, edge cases exist. How does that add to a conversation about an article that’s actually exploring those edge cases?
- knorker 5y ago
  > Hahaha, oh god. Those entire article and discussion is all about implementation detail of date time storage, and why it does effect things. Please keep a more respectful tone. I disagree. It's talking about much higher level things, things which are both more interesting and harder to solve. > Every meeting involving humans involves a physical location Yes, but not necessarily one predetermined one. > So you need pick somewhere It's one way to do it, but it's not the only way. E.g. UTC is not a place. As I understand it the US military is heavy on Zulu. > Great, so your contribution to this topic is to state the obvious, then say be careful, edge cases exist. I'm sorry you don't understand my points about what is hard about time programming.
  - avianlyric 5y ago
    > I'm sorry you don't understand my points about what is hard about time programming. Could you try making your points a littler clearer and easier to understand? Voting strongly suggests I’m not the only one unable to understand you.