Storing Times for Human Events
What’s wrong with calculating the exact UTC time the event is starting and storing only that?
[…]
It’s surprisingly common for countries to make decisions about DST with very little notice. Turkey and Russia and Chile and Morocco are four more examples of countries that can often cause short-term chaos for software developers in this way.
[…]
My strong recommendation here is that the most important thing to record is the original user’s intent. If they said the event is happening at 6pm, store that! Make sure that when they go to edit their event later they see the same editable time that they entered when they first created it.
In addition to that, try to get the most accurate possible indication of the timezone in which that event is occurring.
Previously:
Update (2026-06-04): Helge Heß:
Storing times in UTC is the storing money in Float/Double of the calendaring world. Everyone does it despite feeling it may be wrong for some reason, and will be surprised eventually 🙈
[…]
If the times are UTC you can store them as UTC, but the majority of times apps deal with are not UTC and you can’t store them as such because for future events you can’t know what they are in UTC. It would even differ on location because timezones are a political construct that can and will change.
2 Comments RSS · Twitter · Mastodon
SWATCH .Beat for the win! Well, actually no. But it is a good idea. https://www.swatch.com/sv-se/internet-time.html
@Kristoffer sounds interesting. But Americans are still struggling with the metric system. We can’t even agree on whether DST is a good idea or what to do about it.
I know it’s not a serious suggestion, but time is a funny thing. Both absolute, and yet highly subject to interpretation.
On topic, I think the key point is correct. We aren’t yet global enough to need a truly universal time system. Just need to keep things in the same frame of reference.
