3 ms·
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
by 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 agoYou'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 agoI 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.