Timezone Storage Debate
Discussions center on best practices for storing dates and times in software, debating UTC-only storage versus preserving local timezone information due to issues like DST changes and future events.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Unfortunately timezones have the nasty ability to change.See: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
One wonders, why don't they just use UTC ?
Can't you just use UTC? Isn't that basically exactly what it is?
Why not just explicitly use UTC everywhere?
Doesn't help you much if you stored an UTC for a future meeting, then the TZ rules change, and then you show up an hour late.
This isn't true.For example: If a user schedules an event to happen at 15:35 on July 29th 2021 IST, you cannot know with certainty what the equivalent UTC value is. You know what it would be assuming the relationship between IST and UTC stays the same between now and next year. If India suddenly decides to implement some sort of DST, or make any other changes to the definition to IST, the UTC value you stored is now wrong.Timezones are political, but they're also ho
What's the use case for storing a time with timezone instead of just storing the UTC value?
Maybe you aren't on top of keeping your timezone database up to date, maybe you have to deal with dates spanning 2005, maybe Ontario will finally abolish DST. Using UTC simplifies time handling with very little downside.
This falls down if the timezones themselves change. e.g. if DST was planned, but was then cancelled. You really want to store the original time with timezone as well as UTC.
yes, this is a very big problem for devs who practice tutorial oriented programming and store and transmit local times.