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