4 ms·
The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone.
by wizardry90210 11y ago
The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user.
Storing UTC offsets means that any future political changes will result in the wrong local times for users.
- lambda 11y agoI think the main thing to remember is that dates and times have very different semantics when used for different purposes. If you are referring to an instant in time, then just using UTC is reasonable. If you are referring to a past event and both the local time and precise instant are relevant, then the local time with a timezone offset is reasonable. If you are scheduling events on a calendar, however, like "8 AM every monday for the next four weeks", then yes, you need to store the abstract time zone name so that the calendar program can translate each instance of that schedule to the appropriate instant.
- kristiandupont 11y agoWhich is why you are both right: Offsets are good for past events, time zones for future ones. It's a real pain to deal with..
- bch 11y agoIf you're using the Olsen Database[0], aren't past (and future) changes all handled properly? [0] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database See: Example zone and rule lines
- kelnos 11y agoI suppose storing the offset is safer, because you have in a single string all you need to know to convert the time to UTC, but yes, that was my thought as well -- given a non-broken copy of tzdata, historical dates should be correctly convertible if all you have is a date/time and a timezone name.
- nvivo 11y agoStoring the offset won't work for future dates due to daylight savings changes.
- kelnos 11y agoTrue, but who cares? We're not talking about future dates, we're talking about recording a current timestamp, at which time we of course know the time zone and whether or not DST is in effect at that current point.
- Zarel 11y agoI wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
- saurik 11y agoCST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.
- Zarel 11y agoMy bad, I'll update my comment.
- wtallis 11y agoAnd more commonly, EST doesn't mean just Eastern.
- kelnos 11y agoSure, but the parent didn't say "CST". For a user-facing interface, presenting random city names is terrible. "Central Time" is a known entity among users, and they implicitly assume that it will take care of the difference between CST and CDT (and in fact, the named timezone CST6CDT does exactly that). Hell, if Chicago one day decided to be like a few of the "weird" US cities and not follow the standard DST schedule anymore, then "America/Chicago" would suddenly not represent most of the users in what's colloquially known as "Central Time". Better to use a name like "CST6CDT" that's independent of a particular city, and thus independent of the political whims of a local government.
- justincormack 11y agoNot necessarily. I am giving a talk in San Marcos, TX at 11am next week, but I have no idea what time zone it is in as I am not American.
- notfoss 11y agoYeah, this comment is so spot on, considering that North Korea just announced a new timezone for themselves.