Sorry, why would you be “boned” if you have UTC time? Are you thinking of the case where the desired behavior is to preserve the local time, rather than the absolute time?
I think the comment is specifically talking about storing future times, and contemplating future changes to the local time zone offsets.
If I say that something is going to happen at noon local time on July 1, 2030 in New York, we know that is, under current rules, going to happen at 16:00 UTC. But what if the US changes its daylight savings rules between now and 2030? The canonical time for that event is noon local time, and the offset between local time and UTC can only certainly be determined with past events, so future events defined by local will necessarily have some uncertainty when it comes to UTC.
So many things would be fucked by a TZ change that it very rarely makes sense to consider it.
You’re making a calendar app? Fuck it…some folks are gonna get confused…solved by simply emailing your users and telling them to reschedule shit because there’s kind of a big event going on that everyone knows about and has been planning for for years. Hell in all liklihood this is probably easily solved by simply doing a mass migration of events scheduled before the TZ change.
You’re coding for nuclear weapons? Maybe consider it. But probably not.
That is to say: there are ways to solve problems without resorting to writing the most complicated bullshit code ever seen. Unless of course you work on my team - in which case you’d be right at home.
There is one big caveat to universal time:
Future dates: If you use utc here and a time zone definition changes, you’re boned. You have to store local time and offset for just this one usecase.
Store absolute time in something like Epoch (seconds since 1970-01-01) plus local time zone
Sorry, why would you be “boned” if you have UTC time? Are you thinking of the case where the desired behavior is to preserve the local time, rather than the absolute time?
Not exactly boned but it probably doesn’t make practical difference to store “local time + tzinfo timezone” than just UTC time.
Even if you store everything in UTC, you may be safe… but figuring out the local time is still convoluted and involves a trip through tzinfo.
I think the comment is specifically talking about storing future times, and contemplating future changes to the local time zone offsets.
If I say that something is going to happen at noon local time on July 1, 2030 in New York, we know that is, under current rules, going to happen at 16:00 UTC. But what if the US changes its daylight savings rules between now and 2030? The canonical time for that event is noon local time, and the offset between local time and UTC can only certainly be determined with past events, so future events defined by local will necessarily have some uncertainty when it comes to UTC.
I’m pretty sure that things like the tz database exist exactly for such a case.
The TZ database doesn’t tell us what the offsets will be in the future. Only the past.
So many things would be fucked by a TZ change that it very rarely makes sense to consider it.
You’re making a calendar app? Fuck it…some folks are gonna get confused…solved by simply emailing your users and telling them to reschedule shit because there’s kind of a big event going on that everyone knows about and has been planning for for years. Hell in all liklihood this is probably easily solved by simply doing a mass migration of events scheduled before the TZ change.
You’re coding for nuclear weapons? Maybe consider it. But probably not.
That is to say: there are ways to solve problems without resorting to writing the most complicated bullshit code ever seen. Unless of course you work on my team - in which case you’d be right at home.
nice word choice