2 ms·
UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can
by feld 11y ago
UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application.
If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules.
Always store in UTC. Your argument makes no sense.
- laut 11y agoIf the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing. If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
- feld 11y agoCongratulations you literally just rescheduled the event. This is not a timezone issue. The date should still be stored as UTC.
- Avernar 11y agoWrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500). You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST. Now your system will say the event is at 7pm local time. YOU just rescheduled the event. Works the same with dates and not just times. If you store each of those events individually and the politicians move the DST switch date (or an error was corrected in the TZ database) then some of your event times will now be an hour off.
- feld 11y agoThe event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled. UTC is still the correct way to store it if you want it to be timezone-aware. If every event a specific application needs to be at local time regardless of what the timezone is, stop storing any reference to a timezone.
- Avernar 11y agoWe don't agree. It was not rescheduled in reality. Your system would have said it was rescheduled to 7pm Toronto time while in reality the event would still be 6pm Tronto time. The people using your site/app/whatever would be an hour late. UTC is the correct was to store timestamps (things that happened) and intervals (things that need to happen x seconds/minutes/hours from now). For future events at a specific geographical location you need to store it as local time + timezone. Many databases have a time+timezone type.
- halostatue 11y agoI would go as far to say that the timezone stored should be a named, geographically-based timezone (e.g., America/New York or Canada/Eastern) as opposed to a timezone offset. (If you store the timezone as EDT or EST, you have still encoded -0400 or -0500.)
- Avernar 11y agoThe postgres documentations says exactly that. Other databases might do something else so it's best to read the documentation.
- feld 11y agobut a DST change is a government-mandated rescheduling of the entire lives of its citizens within that jurisdiction :-)
- jasode 11y ago
- jasode 11y ago>Congratulations you literally just rescheduled the event. What does that mean to reschedule? Run a SQL batch job on the database to shift the UTC times by 1 hour?!? Which rows? All of them? Or the rows for a particular TZ? (Better make sure that SQL WHERE clause is error free.) You're just recreating the ambiguity problem but from a different direction. The issue you keep missing is the UTC is ambiguous when attempting to store the scheduling intentions of the user. If the user wants to store a future socially-constructed datetime, storing it purely as UTC will throw away information.
- deleted 11y ago[deleted]