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.
(This is genuinely a simple example, it gets worse 😁)
Yeah, I’ve had my share of timezone madness, but usually anytime timezones are involved, the DST doesn’t cause too much more extra work (except for potentially creating invalid times in the spring you have to handle).
It’s been a while, but i worked on something similar long ago, and the way we did it was in the user’s profile, store the TZ identifier, so for example Europe/Berlin. We had alerts for users stored in an alerts table, and there was a column for “last sent” and “next scheduled”. Everytime an alert was sent, it would check the user’s profile and use the TZ info to generate the UTC time that the next email should go out and update “next scheduled” field with the UTC value. Granted the options for the schedule were fairly limited (every hour, every day, every month), but it worked pretty flawlessly from what I recall.
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.
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.
(This is genuinely a simple example, it gets worse 😁)
Yeah, I’ve had my share of timezone madness, but usually anytime timezones are involved, the DST doesn’t cause too much more extra work (except for potentially creating invalid times in the spring you have to handle).
It’s been a while, but i worked on something similar long ago, and the way we did it was in the user’s profile, store the TZ identifier, so for example
Europe/Berlin. We had alerts for users stored in an alerts table, and there was a column for “last sent” and “next scheduled”. Everytime an alert was sent, it would check the user’s profile and use the TZ info to generate the UTC time that the next email should go out and update “next scheduled” field with the UTC value. Granted the options for the schedule were fairly limited (every hour, every day, every month), but it worked pretty flawlessly from what I recall.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.