But there is no point in time without a location and I think this is the point of the article. The quirk is that the offset to UTC might not be static because of timezone changes, and saving UTC doesn't capture that.
What I've found is that if you save the UTC timestamp + an IANA time zone (e.g. Europe/Paris) you are good. How you convert time for a given IANA time zone at a given UTC time should be consistent. For example in 2024-07-23T10:00:00Z, Europe/Paris should use the offset for the CEST timezone (UTC +02:00 hours).
If at a later point EU gets rid of daylight savings time and France decides to stay on CET year around, date libraries can account for this when you parse the UTC date string and convert it to the provided IANA time zone.
So UTC + IANA time zone gives you an accurate point in local time as long as your date libraries handles IANA time zones correctly.
The author actually made the point in the beginning of the article.
> When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say.
But what if you're not actually storing "a point in time" but actually storing a "time at a location"? The trick is to follow the Stack Overflow advice, but just in the opposite direction. You store the time as a "wall time", and don't store a timezone or an offset, and convert it to UTC (an actual point in time) at the last minute possible.
For a given location, what timezone or daylight savings rules it's going to follow, are always up for change, so the only thing you know for sure is the "wall time" and the "location". Waiting till the last minute maximizes the chance that you've got the latest time library with the latest rules, so it follows the same principle as the Stack Overflow advice.
Now, my opinion might also be colored by experience working in the rental car industry, because the primary goal there is what the customer experiences. Because in their mind, they set up their rental in Phoenix, AZ to start at 9am, so when they're at the counter, and it says 9am on the "wall", the car better be there. They don't want to hear that time zone rules for Phoenix changed in the 6 months since they placed the rental, so "technically" their rental doesn't start until 10am. So in our database, we actually just store "07/23/2024;0900;Phoenix". It's actually incorrect to even store a timezone or an offset, because there's no guarantee those won't change, only the location won't change, so you have to do the lookup for the timezone and the rules for the given location at the very last minute, maximizing your chances of having all the latest time library updates.
If I want to meet an alien species in Jupiter we're not going to coordinate using Earth's calendar. Doesn't mean it's impossible to meet just because they don't know Earth's calendar, we just have to specify a point in TIME without resorting to Earth's calendars. And points in TIME don't depend on timezone changes. Points in the calendar do.
A "timezone" is a map from point in time to point in the calendar. And a "timezone change" is an operation that takes a point in time from one point in the calendar to a different point in the calendar.
> The quirk is that the offset to UTC might not be static because of timezone changes,
An offset to UTC by definition does not depend on timezone, the same way that integers don't depend on timezones. 5 is 5 regardless of the timezone. If I say offset=3711, that has nothing to do with timezones.
You're confusing time with calendar.
> If you want to represent a point in a calendar, use local timezone.
And actually, going back to the original comment, this part was covered by the article. Storing timezone doesn't cover the case of a location switching between timezones.
So it seems the article can't be summed up in a simple rule like the original comment contends.
> And it seems a bit pedantic to separate it
I would say that the fact that you can't see a distinction between time and a calendar is precisely the reason you're confused. So I wouldn't consider it pedantic.
There is no absolute time in spacetime, so your calendar invite from an alien friend would include not only the coordinates on Jupiter but also a time value relative to something. Possibly Earth. Maybe even UTC, as observed on Earth.
In retrospective I wish I'd chosen a less fantastical example, because of course people are gonna get distracted. "Aliens" was not the point. But now I can't be bothered anymore, losing interest fast.