undefined | Better HN

0 pointsfeld10y ago0 comments

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.

0 comments

4 comments · 1 top-level

laut10y ago· 3 in thread

If 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.

feldOP10y ago

Congratulations you literally just rescheduled the event. This is not a timezone issue. The date should still be stored as UTC.

jasode10y 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.

Avernar10y ago

Wrong. 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.

1 more reply

j / k navigate · click thread line to collapse