4 ms·
And that doesn't even get into the problem of the DST dates changing at the whim of legislation like it did recently in the US about 5 years ago. If you are att
by angstrom 15y ago
And that doesn't even get into the problem of the DST dates changing at the whim of legislation like it did recently in the US about 5 years ago. If you are attempting to track timezone instead of UTC you've now have to check date ranges when different DST was in effect. Very messy stuff. Better to just keep it in UTC or Unix if you need the offset it was recorded in as you mentioned.
- JohnLBevan 15y agoTalking of the DST point, how do you manage this in your apps? Say we're in the UK, you schedule something to run at 9am GMT. In the summer, the timezone changes to BST, so 9am GMT is still 9am UTC. I've never seen a scheduling app where you say 9am UK, and have it automatically switch GMT to BST. The closest I've seen is "use server time" where you have to setup the server to automatically apply the DST rules - but then you have issues when working with out of sync DST rules, such as those of the US.
- samspot 15y agoYes to everything stated above. We have a system that schedules events in the future, and the times are all wrong for a couple hours per year because the system is effecting DST @ 12:00am UTC instead of 2:00am local time! Getting time right in all cases is much more challenging than my people realize.