3 ms·

Dont confuse UTC with GMT. Store absolutely everything in UTC, do all calculations on UTC, and show in whatever timeunit the user wants. The one edge-case wher

Dont confuse UTC with GMT. Store absolutely everything in UTC, do all calculations on UTC, and show in whatever timeunit the user wants. The one edge-case where user inputs a local time thats is not unique (repeated hour due to daylight savings time) can easily be solved consistently, and often is not even a problem at all.

em500 8y ago
This is bad advice if you need to store future events/appointments. Because in the majority of cases the meaning of the future datetime is "the date/times on the majority of the calendars and clocks on the wall in the vicinity of the event". The implication is that if the local timezone rules change between now and the future event, the user wants the local datetime of the appointment to stay unchanged, which implies that the UTC/epoch version of the appointment has to be changed. Generating the correct datetimes from UTC/epoch+local timezone requires a lot more administration and logic than storing just the local datetime. (You need at least both the current TZ database and the version when the appointment was made/last changed to have a hope to do this correctly.)
deleted 8y ago
[deleted]
nulbyte 8y ago
That's not the only edge case, and the blog points that out.
philwelch 8y ago
I used to think that, when I was young and naive, which was maybe a month or so ago. Here's a use case: You and I are agreeing to meet at a given landmark. This could be any landmark in the United States, just to keep it simple. The user experience is: you propose that we meet at <landmark> at 4 PM tomorrow, and I agree. This happens on a website. As far as you, me, and most of the system is concerned, the only sensible way to store that time is as a timezone-agnostic, UTC-agnostic local time: "2019-03-28T16:00". That's because, for the system to store that time as UTC, we have to know the UTC offset of every landmark in the United States at any point in time (which isn't an easy problem!) and consistently, correctly convert between UTC and that local time every time it gets displayed anyway. If we screwed up the UTC offset when we stored it the first time, we have to change the UTC time. Now, if there's an additional constraint that you can only schedule meeting times that are actually in the future, you have to know what times constitute "the future" relative to the UTC offset of the landmark, so you don't get out of needing a comprehensive UTC offset map of the United States. But if you screw that up, you just end up putting an irrelevant or impossible meeting time in a dropdown and maybe dealing with some users attempting to time travel. Even that is a failure mode that users will somewhat understand, but most of the time it won't matter unless users are scheduling within the same time window as your UTC error. If you stored it in UTC, you'd be screwing it up all the damn time until you fixed your UTC offsets, at which point previously-working data would be incorrect because someone would schedule a meeting 8 days out in one of those geographic regions for 6 PM and suddenly wonder how it got shifted to 5 PM for no reason. Now, if we're scheduling a meeting online, and videoconferencing instead of traveling to the Navajo Reservation in Arizona--of course we store it in UTC. And if some of us are traveling to the Navajo Reservation[1] and some of us are dialing in from Newfoundland[2], we're all fucked anyway. [1] The Navajo Indian Reservation spans multiple states, including Arizona. Arizona does not observe DST. The Navajo Indian Reservation does. However, inside the Arizona portion of the Navajo reservation, there is a Hopi Indian Reservation, which does not observe DST. Inside of the Hopi reservation, there is another part of the Navajo reservation that does observe DST. [2] Newfoundland's UTC offset isn't an integer number of hours, there's an extra half hour in there. Enjoy!
- barrystaes 8y ago
  Your examples indeed show common problems with several approaches when place is coupled to a time and then proceed to ignore the place (of meeting or user) when converting times. I should add that where we store UTC that concerns a place, we also know/store that place in lat,long (or anything that resolves to this) and use that to show it in any timezone, to any user in any timezone, ..even in any era (yes places can change timezone).
seniorsassycat 8y ago
The author did not confuse GMT for UTC. I live in Seattle, I set a reminder on my phone one minute before new years 2021. date --date "2021-01-01T07:59+00:00" Thu Dec 31 23:59:00 PST 2020 Currently Washington follows daylight saving time so we'll be using PST on new years eve. Washington lawmakers are considering a bill to end daylight saving time. If it passes then new years eve 2020 will be PDT, not PST 2021-01-01T07:59+00:00 is midnight PST but it is 1:00 AM PDT and my alarm will be off by an hour.

em500 8y ago

This is bad advice if you need to store future events/appointments. Because in the majority of cases the meaning of the future datetime is "the date/times on the majority of the calendars and clocks on the wall in the vicinity of the event". The implication is that if the local timezone rules change between now and the future event, the user wants the local datetime of the appointment to stay unchanged, which implies that the UTC/epoch version of the appointment has to be changed. Generating the correct datetimes from UTC/epoch+local timezone requires a lot more administration and logic than storing just the local datetime. (You need at least both the current TZ database and the version when the appointment was made/last changed to have a hope to do this correctly.)

deleted 8y ago

[deleted]

nulbyte 8y ago

That's not the only edge case, and the blog points that out.

philwelch 8y ago

I used to think that, when I was young and naive, which was maybe a month or so ago. Here's a use case: You and I are agreeing to meet at a given landmark. This could be any landmark in the United States, just to keep it simple. The user experience is: you propose that we meet at <landmark> at 4 PM tomorrow, and I agree. This happens on a website. As far as you, me, and most of the system is concerned, the only sensible way to store that time is as a timezone-agnostic, UTC-agnostic local time: "2019-03-28T16:00". That's because, for the system to store that time as UTC, we have to know the UTC offset of every landmark in the United States at any point in time (which isn't an easy problem!) and consistently, correctly convert between UTC and that local time every time it gets displayed anyway. If we screwed up the UTC offset when we stored it the first time, we have to change the UTC time. Now, if there's an additional constraint that you can only schedule meeting times that are actually in the future, you have to know what times constitute "the future" relative to the UTC offset of the landmark, so you don't get out of needing a comprehensive UTC offset map of the United States. But if you screw that up, you just end up putting an irrelevant or impossible meeting time in a dropdown and maybe dealing with some users attempting to time travel. Even that is a failure mode that users will somewhat understand, but most of the time it won't matter unless users are scheduling within the same time window as your UTC error. If you stored it in UTC, you'd be screwing it up all the damn time until you fixed your UTC offsets, at which point previously-working data would be incorrect because someone would schedule a meeting 8 days out in one of those geographic regions for 6 PM and suddenly wonder how it got shifted to 5 PM for no reason. Now, if we're scheduling a meeting online, and videoconferencing instead of traveling to the Navajo Reservation in Arizona--of course we store it in UTC. And if some of us are traveling to the Navajo Reservation[1] and some of us are dialing in from Newfoundland[2], we're all fucked anyway. [1] The Navajo Indian Reservation spans multiple states, including Arizona. Arizona does not observe DST. The Navajo Indian Reservation does. However, inside the Arizona portion of the Navajo reservation, there is a Hopi Indian Reservation, which does not observe DST. Inside of the Hopi reservation, there is another part of the Navajo reservation that does observe DST. [2] Newfoundland's UTC offset isn't an integer number of hours, there's an extra half hour in there. Enjoy!

barrystaes 8y ago
Your examples indeed show common problems with several approaches when place is coupled to a time and then proceed to ignore the place (of meeting or user) when converting times. I should add that where we store UTC that concerns a place, we also know/store that place in lat,long (or anything that resolves to this) and use that to show it in any timezone, to any user in any timezone, ..even in any era (yes places can change timezone).

seniorsassycat 8y ago

The author did not confuse GMT for UTC. I live in Seattle, I set a reminder on my phone one minute before new years 2021. date --date "2021-01-01T07:59+00:00" Thu Dec 31 23:59:00 PST 2020 Currently Washington follows daylight saving time so we'll be using PST on new years eve. Washington lawmakers are considering a bill to end daylight saving time. If it passes then new years eve 2020 will be PDT, not PST 2021-01-01T07:59+00:00 is midnight PST but it is 1:00 AM PDT and my alarm will be off by an hour.