10 ms·

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

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 2y ago
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 https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database)
- lxgr 2y ago
  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 2y ago
    I appreciate those longer lists, though they do have some bizarre omissions.
- thaumasiotes 2y ago
  > 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.

filleokus 2y ago

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 https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database)

lxgr 2y ago
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 2y ago
  I appreciate those longer lists, though they do have some bizarre omissions.
thaumasiotes 2y ago
> 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.