[e28eta]

It was checking for something like “is it 9am in PST / PDT right now? What about EST / EDT?”

Or maybe, “what’s the current time in this list of time zones and then I’ll send notifications to users where it’s 9am”

Or something, I don’t specifically remember. The point is that notifications aren’t generated until they’re supposed to be sent, and we didn’t want that to vary by 1 hour with daylight savings.

And this specific use case aside, I think it’s true that there’s a class of use cases where developers do need to consider DST.

[takinola]

I have no doubt that this may have been some crazy complicated case (as dealing with time can be) but I can't help the armchair quarterback debugging. Could this not have been addressed by periodically running a script that generated when (in UTC) a notification should be sent and then another script to send the notifications when that time comes around ie

Script 1: send notification to User 123 at 9:00 UTC

Script 2: It is 9:00 UTC, which users are due to have notifications that have not been sent?

This way, the timezones don't ever really come into play. The axiom I follow for dealing with time is collect and display time in user's local time but store and process in UTC.

[e28eta]

If you choose to divide it like that, script 1 is the one that needs to know about DST, because user 123 might be 9 UTC today, but what is it tomorrow?

Might change due to a DST change (which varies by time zone, and time zone DST date can change year-to-year), or the user might change time zones. Either way, your Script 1 is the logic that had the bug I inherited.