Let's say I'm sorting some information about an event occuring in Florida, USA next year. It will be on July 4th at 3:00pm. I store this as an ISO string: "2025-07-04T03:00:00Z-5".
Florida (and the USA as a whole) have been discussing getting rid of the daylight savings change on-and-off for several years.
If that law goes through in December of this year, the date I stored for my event will now be off by an hour because come July 2025 Florida will be on UTC offset -6, not -5.
On the other hand, if I store the date with a fully qualified tz database timezone like this: "2025-07-04 03:00:00 America/New_York" the time will continue to be displayed correctly because the tz database will be updated with the new offset information.
If the calendar application want to be really accurate in a couple of years it's probably best to ask the user for coordinates for the event. You never know if that spot in Florida will be part of America/New_York next year.
> You never know if that spot in Florida will be part of America/New_York next year.
The example really threw me; in the case where you assume that Florida stops observing DST, Florida is definitely not going to be part of America/New_York, so that example is guaranteed to have the same problem as the UTC timestamp.
You're highlighting an important edge case here: The TZ database only splits regions reactively, not proactively.
But an actual lat/long pair is often neither available, nor desirable to be stored for various reasons.
Now that you mention it, I think I've seen some web applications that had a list of cities much longer than what's present in the TZ database for calendar scheduling purposes, probably to accomodate for just that future edge case.
Florida (and the USA as a whole) have been discussing getting rid of the daylight savings change on-and-off for several years.
If that law goes through in December of this year, the date I stored for my event will now be off by an hour because come July 2025 Florida will be on UTC offset -6, not -5.
On the other hand, if I store the date with a fully qualified tz database timezone like this: "2025-07-04 03:00:00 America/New_York" the time will continue to be displayed correctly because the tz database will be updated with the new offset information.