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