Not the person you responded to , but the “render local time on the client side” is the tricky part, especially when the time is in the past or future relative to current. Theres a hundred edge cases to consider and many of them very non-obvious to our feeble linear time oriented mortal minds.
Yes, I’m familiar with the Tom Scott video, but even he says at the end to store data in UTC and use a library like tzdata for rendering, don’t do it yourself. I was more curious about what day to day issues were happening because of DST, since that seems like bad implementation, and not an impossible problem that would be causing half of all IT issues.
So as s simple example from the system I work with:
Customers can set rolling validities for alerts, e.g., Monday 8-10.
If a customer from a place which currently has DST puts in 8-10 say, CEST, in their browser (6-8 UTC) then they intuitively expect this to still be 8-10 their local time (7-9 UTC) when later winter time rolls around.
But, all data checked for alerts comes in in UTC and different users editing these validities are from different countries, timezones and summer time preferences.
Gets funky really quickly. Especially because the evaluation has to account for the DST shift essentially on a per-recipient DST when configured vs DST when evaluated basis.
I manage a bunch of code that has to handle that sort of thing, since no customers have complained I haven’t had to check into it. Now that I’ve typed this I imagine I’ll get an issue next week cause last person who did it wasn’t so great with that stuff. Seems to work so easier to let it be till it doesn’t.
Mostly installed locally but we do have some hosted customers on central servers, either they haven’t noticed issues or it works. I’d put money on the former than latter though.
What sorts of issues? It’s been common for decades to store time in UTC, and render local time on the client side.
Not the person you responded to , but the “render local time on the client side” is the tricky part, especially when the time is in the past or future relative to current. Theres a hundred edge cases to consider and many of them very non-obvious to our feeble linear time oriented mortal minds.
Yes, I’m familiar with the Tom Scott video, but even he says at the end to store data in UTC and use a library like tzdata for rendering, don’t do it yourself. I was more curious about what day to day issues were happening because of DST, since that seems like bad implementation, and not an impossible problem that would be causing half of all IT issues.
So as s simple example from the system I work with:
Customers can set rolling validities for alerts, e.g., Monday 8-10.
If a customer from a place which currently has DST puts in 8-10 say, CEST, in their browser (6-8 UTC) then they intuitively expect this to still be 8-10 their local time (7-9 UTC) when later winter time rolls around.
But, all data checked for alerts comes in in UTC and different users editing these validities are from different countries, timezones and summer time preferences.
Gets funky really quickly. Especially because the evaluation has to account for the DST shift essentially on a per-recipient DST when configured vs DST when evaluated basis.
I manage a bunch of code that has to handle that sort of thing, since no customers have complained I haven’t had to check into it. Now that I’ve typed this I imagine I’ll get an issue next week cause last person who did it wasn’t so great with that stuff. Seems to work so easier to let it be till it doesn’t.
Mostly installed locally but we do have some hosted customers on central servers, either they haven’t noticed issues or it works. I’d put money on the former than latter though.