6 ms·

I've said for ages that programmers only need two subjects to learn. Date and time programming and debugging. The first one leads naturally to the second one.

by rswail 5y ago

I've said for ages that programmers only need two subjects to learn. Date and time programming and debugging. The first one leads naturally to the second one. The rules I follow: 1. If you're recording an event in the past, store it in UTC. 2. If you need to record the local time for something either in the past or the future, store it as the local time as it was (for the past), or the local time as it will be (for the future), plus a timezone (not an offset). 3. If you're displaying a timestamp, a) if you can, display UTC, b) if needed, display in local time using current conversion rules 4. If you are getting user input, a) if you can, get it in UTC, b) if not, get it using a timezone (not an offset) 5. If you are storing a date, then that is not a timestamp. A date is a period, so either just store the date without a timezone, or, if it's a date period in a local area, store the start and end timestamps with their timezones.

knorker 5y ago
> 1. If you're recording an event in the past, store it in UTC. Why not epoch? An integer always means epoch. A human readable timestamp, unless it's exactly ISO8601, is pretty much always ambiguous. > 2. [...] plus a timezone (not an offset). Why not offset? ISO8601 is a good standard. And it takes a very special use case to care about leap seconds. For logging "leap smear" is clearly a better way to solve it, and for time measurements you should always use a monotonic clock, not wall clock. Oh, and with timezone I assume you mean something like "Europe/New_York", not ambiguous like "EST". > A date is a period, so either just store the date without a timezone Of course some dates don't exist in some timezones (and I mean more modern times than gregorian/julian). So you can't count days between two dates without knowing the timezone. 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. (and even with these two you have to be careful)
- samwillis 5y ago
  > Why not offset? An offset would have exactly the same issues as UTC. You need the time zone location to correct for future changes. Knowing it’s UTC+2 doesn’t help with that. Ultimately it comes down to intent, either relative to space time, or the socially excepted time in a particular location in the future. A time zone represented as a location/city name is the best we currently have, but even can can be wrong if the time zone boundary’s change.
  - knorker 5y ago
    You're right, it's down to intent. Where do you anchor your future times. Is the meeting literally two months, four days, three hours, 32 minutes, and 14 seconds from now, or is it two motnhs, four days from now, when a local clock in New York is 15:30? I was thinking international meetings where "your country changed: you move", which in retrospect is not realistic.
- avianlyric 5y ago
  > 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?
- jagged-chisel 5y ago
  With epoch, from whose perspective are units counted? Mine? Someone in Greenwich? Still needs a timezone so determine when something did or will happen.
  - knorker 5y ago
    > With epoch, from whose perspective are units counted? Mine? Someone in Greenwich? That's the great part of about (at least UNIX) epochs. It's the same so it doesn't matter. > Still needs a timezone so determine when something did or will happen. Nope, it does not. That's exactly why it's better. At least for describing exact timestamps, like "when an HTTP request came in". It's less good at describing "no matter what changes are made in political circles, I want to represent noon in this native american tribe in Arkansas today three years from now. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
- deleted 5y ago
  [deleted]
- abdusco 5y ago
  Offsets can change. Turkey switched from GMT+2 with DTS to GMT+3 without DTS a couple of years ago. If you were to store +2, you wouldn't be able to reconstruct the current date from it, while having Europe/Istanbul would give you either +2 or +3 depending on the revision. So a better option is to store UTC + timezone + revision (i.e. timezone as it was in 2014 to figure out the offset later)
  - knorker 5y ago
    > Offsets can change. Indeed. So when the Turkey/France meeting moves, what then? But I get you. You want the point in time to stay "the same" in the local "common sense" time, whereas I was thinking international cooperation in which case anchoring it in Turkey could hurt more than help. > So a better option is to store UTC + timezone + revision Well that means that you've decided on an exact number of seconds from now, no matter how timezones change. So what's the point? Why not just have UTC+offset, then? timezone+revision is exactly equal to offset.
- brandmeyer 5y ago
  > Why not epoch? An integer always means epoch. A human readable timestamp, unless it's exactly ISO8601, is pretty much always ambiguous. Because in practice, the only ubiquitous APIs for getting time since an epoch don't actually model an elapsed time standard. The odd one out is POSIX time.
  - knorker 5y ago
    In theory or in practice, where can you not get POSIX time? (aside from devices with no RTC or for other reasons can't keep any time at all)
    - brandmeyer 5y ago
      POSIX time isn't quite an elapsed time standard, thanks to the absence of leap seconds.
      - knorker 5y ago
        Wall clock time should never be used to measure time when these seconds matter. Like I said in grandparent comment: > for time measurements you should always use a monotonic clock, not wall clock. POSIX time isn't a time elapsed standard. Yes. But neither is iso8601, timestamp+timezone, everyday speak time "tomorrow at noon", or any of these other options. So I'm not sure what your point is, other than to say that a hammer is not a screwdriver.
robin_reala 5y ago
I’ve had bugs with number 5 when I wanted to encode historical dates with a pre-Gregorian calendar. Even timezones on their own don’t help when you need to account for differing calendars.
spacemanmatt 5y ago
> 1. If you're recording an event in the past, store it in UTC. Although it is unlikely for a timezone change to be issued after its begin date, it is likely for a timezone change to be entered into a database after its begin date. If you preserve the original local time you can always convert to UTC accurately.
HWR_14 5y ago
> 1. If you're recording an event in the past, store it in UTC. That works a lot less well when your analytics don't easily show that "make my coffee" is usually run in the mornings, local time.
- coldtea 5y ago
  He said "store". What you describe is "display". You convert for reporting and UI.
  - HWR_14 5y ago
    Then you run into all the problems in the article. Out of date time zones because they changed. Bad initial conversions because of time zone mismatches. Etc.
    - chrishas35 5y ago
      Not when it's an event in the past. When the event in the past you know which TZ rules to apply for conversion. The issues arise for the future because you don't know what change may occur.
      - deleted 5y ago
        [deleted]
- brewmarche 5y ago
  I agree, storing with an offset is better here, e.g. prefer `2022-03-13T08:00-04:00` over `2022-03-13T12:00Z` when the regional time zone of the event location was UTC-4 when the event occurred. Why? As instants they are both equivalent, but one carries additional information, namely the time that was on the wall where and when the event happened. Fixed offsets will never change, so this really is a frozen snapshot
BatteryMountain 5y ago
To piggyback on this, all developers dealing with this should read "Developing Time-Oriented Database Applications in SQL" too.
BiteCode_dev 5y ago
I really think they should learn 10 subjects.
- yakshaving_jgt 5y ago
  Ba-dum, tish!

by rswail 5y ago

knorker 5y ago

> 1. If you're recording an event in the past, store it in UTC. Why not epoch? An integer always means epoch. A human readable timestamp, unless it's exactly ISO8601, is pretty much always ambiguous. > 2. [...] plus a timezone (not an offset). Why not offset? ISO8601 is a good standard. And it takes a very special use case to care about leap seconds. For logging "leap smear" is clearly a better way to solve it, and for time measurements you should always use a monotonic clock, not wall clock. Oh, and with timezone I assume you mean something like "Europe/New_York", not ambiguous like "EST". > A date is a period, so either just store the date without a timezone Of course some dates don't exist in some timezones (and I mean more modern times than gregorian/julian). So you can't count days between two dates without knowing the timezone. 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. (and even with these two you have to be careful)

samwillis 5y ago
> Why not offset? An offset would have exactly the same issues as UTC. You need the time zone location to correct for future changes. Knowing it’s UTC+2 doesn’t help with that. Ultimately it comes down to intent, either relative to space time, or the socially excepted time in a particular location in the future. A time zone represented as a location/city name is the best we currently have, but even can can be wrong if the time zone boundary’s change.
- knorker 5y ago
  You're right, it's down to intent. Where do you anchor your future times. Is the meeting literally two months, four days, three hours, 32 minutes, and 14 seconds from now, or is it two motnhs, four days from now, when a local clock in New York is 15:30? I was thinking international meetings where "your country changed: you move", which in retrospect is not realistic.
avianlyric 5y ago
> 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?
jagged-chisel 5y ago
With epoch, from whose perspective are units counted? Mine? Someone in Greenwich? Still needs a timezone so determine when something did or will happen.
- knorker 5y ago
  > With epoch, from whose perspective are units counted? Mine? Someone in Greenwich? That's the great part of about (at least UNIX) epochs. It's the same so it doesn't matter. > Still needs a timezone so determine when something did or will happen. Nope, it does not. That's exactly why it's better. At least for describing exact timestamps, like "when an HTTP request came in". It's less good at describing "no matter what changes are made in political circles, I want to represent noon in this native american tribe in Arkansas today three years from now. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
deleted 5y ago
[deleted]
abdusco 5y ago
Offsets can change. Turkey switched from GMT+2 with DTS to GMT+3 without DTS a couple of years ago. If you were to store +2, you wouldn't be able to reconstruct the current date from it, while having Europe/Istanbul would give you either +2 or +3 depending on the revision. So a better option is to store UTC + timezone + revision (i.e. timezone as it was in 2014 to figure out the offset later)
- knorker 5y ago
  > Offsets can change. Indeed. So when the Turkey/France meeting moves, what then? But I get you. You want the point in time to stay "the same" in the local "common sense" time, whereas I was thinking international cooperation in which case anchoring it in Turkey could hurt more than help. > So a better option is to store UTC + timezone + revision Well that means that you've decided on an exact number of seconds from now, no matter how timezones change. So what's the point? Why not just have UTC+offset, then? timezone+revision is exactly equal to offset.
brandmeyer 5y ago
> Why not epoch? An integer always means epoch. A human readable timestamp, unless it's exactly ISO8601, is pretty much always ambiguous. Because in practice, the only ubiquitous APIs for getting time since an epoch don't actually model an elapsed time standard. The odd one out is POSIX time.
- knorker 5y ago
  In theory or in practice, where can you not get POSIX time? (aside from devices with no RTC or for other reasons can't keep any time at all)
  - brandmeyer 5y ago
    POSIX time isn't quite an elapsed time standard, thanks to the absence of leap seconds.
    - knorker 5y ago
      Wall clock time should never be used to measure time when these seconds matter. Like I said in grandparent comment: > for time measurements you should always use a monotonic clock, not wall clock. POSIX time isn't a time elapsed standard. Yes. But neither is iso8601, timestamp+timezone, everyday speak time "tomorrow at noon", or any of these other options. So I'm not sure what your point is, other than to say that a hammer is not a screwdriver.

robin_reala 5y ago

I’ve had bugs with number 5 when I wanted to encode historical dates with a pre-Gregorian calendar. Even timezones on their own don’t help when you need to account for differing calendars.

spacemanmatt 5y ago

> 1. If you're recording an event in the past, store it in UTC. Although it is unlikely for a timezone change to be issued after its begin date, it is likely for a timezone change to be entered into a database after its begin date. If you preserve the original local time you can always convert to UTC accurately.

HWR_14 5y ago

> 1. If you're recording an event in the past, store it in UTC. That works a lot less well when your analytics don't easily show that "make my coffee" is usually run in the mornings, local time.

coldtea 5y ago
He said "store". What you describe is "display". You convert for reporting and UI.
- HWR_14 5y ago
  Then you run into all the problems in the article. Out of date time zones because they changed. Bad initial conversions because of time zone mismatches. Etc.
  - chrishas35 5y ago
    Not when it's an event in the past. When the event in the past you know which TZ rules to apply for conversion. The issues arise for the future because you don't know what change may occur.
    - deleted 5y ago
      [deleted]
brewmarche 5y ago
I agree, storing with an offset is better here, e.g. prefer `2022-03-13T08:00-04:00` over `2022-03-13T12:00Z` when the regional time zone of the event location was UTC-4 when the event occurred. Why? As instants they are both equivalent, but one carries additional information, namely the time that was on the wall where and when the event happened. Fixed offsets will never change, so this really is a frozen snapshot

BatteryMountain 5y ago

To piggyback on this, all developers dealing with this should read "Developing Time-Oriented Database Applications in SQL" too.

BiteCode_dev 5y ago

I really think they should learn 10 subjects.

yakshaving_jgt 5y ago
Ba-dum, tish!