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.
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.