5 ms·
Which 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..
by kristiandupont 11y ago
Which 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.