[jayshua]

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.

[filleokus]

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.

(Of course a tz identifier will be better than an integer offset, but I'm only half joking: https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database)

[thaumasiotes]

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

[lxgr]

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.

[BeFlatXIII]

I appreciate those longer lists, though they do have some bizarre omissions.