3 ms·

If you want to represent a point in time, use UTC. If you want to represent a point in a calendar, use local timezone.

dsego 2y ago
But there is no point in time without a location and I think this is the point of the article. The quirk is that the offset to UTC might not be static because of timezone changes, and saving UTC doesn't capture that.
- kjrfghslkdjfl 2y ago
  You're confusing time with calendar. If I want to meet an alien species in Jupiter we're not going to coordinate using Earth's calendar. Doesn't mean it's impossible to meet just because they don't know Earth's calendar, we just have to specify a point in TIME without resorting to Earth's calendars. And points in TIME don't depend on timezone changes. Points in the calendar do. A "timezone" is a map from point in time to point in the calendar. And a "timezone change" is an operation that takes a point in time from one point in the calendar to a different point in the calendar. > The quirk is that the offset to UTC might not be static because of timezone changes, An offset to UTC by definition does not depend on timezone, the same way that integers don't depend on timezones. 5 is 5 regardless of the timezone. If I say offset=3711, that has nothing to do with timezones. You're confusing time with calendar.
  - dsego 2y ago
    I don't think aliens would care about UTC. And it seems a bit pedantic to separate it, humans tend to store times related to events on Earth. > If you want to represent a point in a calendar, use local timezone. And actually, going back to the original comment, this part was covered by the article. Storing timezone doesn't cover the case of a location switching between timezones. So it seems the article can't be summed up in a simple rule like the original comment contends.
    - kjrfghslkdjfl 2y ago
      I didn't say aliens would care about UTC, did I? I said that we would have to specify a point in time without resorting to calendars. I didn't say we would use offset to UTC, because aliens don't know UTC either. But presumably they can measure time, so we could e.g. measure a point in time as an offset to "now". We would also have to use units that they understand. Not seconds, but perhaps Cesium revolutions. > And it seems a bit pedantic to separate it I would say that the fact that you can't see a distinction between time and a calendar is precisely the reason you're confused. So I wouldn't consider it pedantic.
      - dsego 2y ago
        No, you are absolutely right about the distinction, I didn't see it as useful since the article is dealing with calendars here, eg. time of event at some location. I don't think I've used time without a calendar so it seems a bit abstract to do so.
        kjrfghslkdjfl 2y ago
        Every time you say "wait a second" you're using time without a calendar or a timezone. You're referring to a point in time as an offset (1 second) to "now" which is the point in time when you say it, and its the same point regardless of which timezone you're in, or whether there's a timezone change in between.
  - riiii 2y ago
    Timekeeping is hard enough already. Let's leave the aliens aspect out of it.
    - kjrfghslkdjfl 2y ago
      You might be right. I was trying to disentangle "time" from "calendar" by showing that just because someone doesn't know anything about calendars doesn't mean you can't coordinate with them to meet at a future point in time, and THEREFORE you should indeed use an offset to represent points in time and local timezone to represent points in a calendar as I originally claimed. In retrospective I wish I'd chosen a less fantastical example, because of course people are gonna get distracted. "Aliens" was not the point. But now I can't be bothered anymore, losing interest fast.
  - wmal 2y ago
    You wanted to make a point that time does not depend on physical location, while you chose an example that proves otherwise. There is no absolute time in spacetime, so your calendar invite from an alien friend would include not only the coordinates on Jupiter but also a time value relative to something. Possibly Earth. Maybe even UTC, as observed on Earth.
    - Dylan16807 2y ago
      Please don't bring relativity into this except as a fun side note. It doesn't make a meaningful difference for actual objects in space, because they all share basically the same reference frame.
    - kjrfghslkdjfl 2y ago
      [dead]
- snorremd 2y ago
  Exactly. What I've found is that if you save the UTC timestamp + an IANA time zone (e.g. Europe/Paris) you are good. How you convert time for a given IANA time zone at a given UTC time should be consistent. For example in 2024-07-23T10:00:00Z, Europe/Paris should use the offset for the CEST timezone (UTC +02:00 hours). If at a later point EU gets rid of daylight savings time and France decides to stay on CET year around, date libraries can account for this when you parse the UTC date string and convert it to the provided IANA time zone. So UTC + IANA time zone gives you an accurate point in local time as long as your date libraries handles IANA time zones correctly.
  - rezonant 2y ago
    That's all fine, but the problem case as described in TFA is that if the meeting was scheduled for 9AM (perhaps say 06:00 UTC) before the change, but 9AM now means 07:00 UTC, then you can convert that previously saved timestamp back to local time, but it will still be 8AM, which is not when the meeting was scheduled. The humans all arrive at 9AM (an hour later than originally scheduled with respect to UTC, but correct by the clocks on the wall), the software thinks it started an hour ago.
- jmchuster 2y ago
  There are lot of points in time that don't have a location, such as a historical event. Then it's most accurate to store in UTC, then convert to the timezone you want only at display time. The author actually made the point in the beginning of the article. > When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say. But what if you're not actually storing "a point in time" but actually storing a "time at a location"? The trick is to follow the Stack Overflow advice, but just in the opposite direction. You store the time as a "wall time", and don't store a timezone or an offset, and convert it to UTC (an actual point in time) at the last minute possible. For a given location, what timezone or daylight savings rules it's going to follow, are always up for change, so the only thing you know for sure is the "wall time" and the "location". Waiting till the last minute maximizes the chance that you've got the latest time library with the latest rules, so it follows the same principle as the Stack Overflow advice. Now, my opinion might also be colored by experience working in the rental car industry, because the primary goal there is what the customer experiences. Because in their mind, they set up their rental in Phoenix, AZ to start at 9am, so when they're at the counter, and it says 9am on the "wall", the car better be there. They don't want to hear that time zone rules for Phoenix changed in the 6 months since they placed the rental, so "technically" their rental doesn't start until 10am. So in our database, we actually just store "07/23/2024;0900;Phoenix". It's actually incorrect to even store a timezone or an offset, because there's no guarantee those won't change, only the location won't change, so you have to do the lookup for the timezone and the rules for the given location at the very last minute, maximizing your chances of having all the latest time library updates.

But there is no point in time without a location and I think this is the point of the article. The quirk is that the offset to UTC might not be static because of timezone changes, and saving UTC doesn't capture that.

kjrfghslkdjfl 2y ago
You're confusing time with calendar. If I want to meet an alien species in Jupiter we're not going to coordinate using Earth's calendar. Doesn't mean it's impossible to meet just because they don't know Earth's calendar, we just have to specify a point in TIME without resorting to Earth's calendars. And points in TIME don't depend on timezone changes. Points in the calendar do. A "timezone" is a map from point in time to point in the calendar. And a "timezone change" is an operation that takes a point in time from one point in the calendar to a different point in the calendar. > The quirk is that the offset to UTC might not be static because of timezone changes, An offset to UTC by definition does not depend on timezone, the same way that integers don't depend on timezones. 5 is 5 regardless of the timezone. If I say offset=3711, that has nothing to do with timezones. You're confusing time with calendar.
- dsego 2y ago
  I don't think aliens would care about UTC. And it seems a bit pedantic to separate it, humans tend to store times related to events on Earth. > If you want to represent a point in a calendar, use local timezone. And actually, going back to the original comment, this part was covered by the article. Storing timezone doesn't cover the case of a location switching between timezones. So it seems the article can't be summed up in a simple rule like the original comment contends.
  - kjrfghslkdjfl 2y ago
    I didn't say aliens would care about UTC, did I? I said that we would have to specify a point in time without resorting to calendars. I didn't say we would use offset to UTC, because aliens don't know UTC either. But presumably they can measure time, so we could e.g. measure a point in time as an offset to "now". We would also have to use units that they understand. Not seconds, but perhaps Cesium revolutions. > And it seems a bit pedantic to separate it I would say that the fact that you can't see a distinction between time and a calendar is precisely the reason you're confused. So I wouldn't consider it pedantic.
    - dsego 2y ago
      No, you are absolutely right about the distinction, I didn't see it as useful since the article is dealing with calendars here, eg. time of event at some location. I don't think I've used time without a calendar so it seems a bit abstract to do so.
      - kjrfghslkdjfl 2y ago
        Every time you say "wait a second" you're using time without a calendar or a timezone. You're referring to a point in time as an offset (1 second) to "now" which is the point in time when you say it, and its the same point regardless of which timezone you're in, or whether there's a timezone change in between.
- riiii 2y ago
  Timekeeping is hard enough already. Let's leave the aliens aspect out of it.
  - kjrfghslkdjfl 2y ago
    You might be right. I was trying to disentangle "time" from "calendar" by showing that just because someone doesn't know anything about calendars doesn't mean you can't coordinate with them to meet at a future point in time, and THEREFORE you should indeed use an offset to represent points in time and local timezone to represent points in a calendar as I originally claimed. In retrospective I wish I'd chosen a less fantastical example, because of course people are gonna get distracted. "Aliens" was not the point. But now I can't be bothered anymore, losing interest fast.
- wmal 2y ago
  You wanted to make a point that time does not depend on physical location, while you chose an example that proves otherwise. There is no absolute time in spacetime, so your calendar invite from an alien friend would include not only the coordinates on Jupiter but also a time value relative to something. Possibly Earth. Maybe even UTC, as observed on Earth.
  - Dylan16807 2y ago
    Please don't bring relativity into this except as a fun side note. It doesn't make a meaningful difference for actual objects in space, because they all share basically the same reference frame.
  - kjrfghslkdjfl 2y ago
    [dead]
snorremd 2y ago
Exactly. What I've found is that if you save the UTC timestamp + an IANA time zone (e.g. Europe/Paris) you are good. How you convert time for a given IANA time zone at a given UTC time should be consistent. For example in 2024-07-23T10:00:00Z, Europe/Paris should use the offset for the CEST timezone (UTC +02:00 hours). If at a later point EU gets rid of daylight savings time and France decides to stay on CET year around, date libraries can account for this when you parse the UTC date string and convert it to the provided IANA time zone. So UTC + IANA time zone gives you an accurate point in local time as long as your date libraries handles IANA time zones correctly.
- rezonant 2y ago
  That's all fine, but the problem case as described in TFA is that if the meeting was scheduled for 9AM (perhaps say 06:00 UTC) before the change, but 9AM now means 07:00 UTC, then you can convert that previously saved timestamp back to local time, but it will still be 8AM, which is not when the meeting was scheduled. The humans all arrive at 9AM (an hour later than originally scheduled with respect to UTC, but correct by the clocks on the wall), the software thinks it started an hour ago.
jmchuster 2y ago
There are lot of points in time that don't have a location, such as a historical event. Then it's most accurate to store in UTC, then convert to the timezone you want only at display time. The author actually made the point in the beginning of the article. > When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say. But what if you're not actually storing "a point in time" but actually storing a "time at a location"? The trick is to follow the Stack Overflow advice, but just in the opposite direction. You store the time as a "wall time", and don't store a timezone or an offset, and convert it to UTC (an actual point in time) at the last minute possible. For a given location, what timezone or daylight savings rules it's going to follow, are always up for change, so the only thing you know for sure is the "wall time" and the "location". Waiting till the last minute maximizes the chance that you've got the latest time library with the latest rules, so it follows the same principle as the Stack Overflow advice. Now, my opinion might also be colored by experience working in the rental car industry, because the primary goal there is what the customer experiences. Because in their mind, they set up their rental in Phoenix, AZ to start at 9am, so when they're at the counter, and it says 9am on the "wall", the car better be there. They don't want to hear that time zone rules for Phoenix changed in the 6 months since they placed the rental, so "technically" their rental doesn't start until 10am. So in our database, we actually just store "07/23/2024;0900;Phoenix". It's actually incorrect to even store a timezone or an offset, because there's no guarantee those won't change, only the location won't change, so you have to do the lookup for the timezone and the rules for the given location at the very last minute, maximizing your chances of having all the latest time library updates.