4 ms·
> This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. No, this only works for datetimes
by autarch 3y ago
> This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users.
No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://www.theguardian.com/world/2011/dec/30/samoa-loses-day-date-line https://www.theguardian.com/world/2011/dec/30/samoa-loses-da....
- Spivak 3y agoThank god someone in the thread understands the problem. Everyone saying "just make everything UTC and convert" is both throwing away information and making it impossible to do future calculations. "Schedule a 1-1 with my boss every two weeks at 1 PM" If you take my local time zone, convert it to UTC which puts my meeting at say 9AM UTC, schedule every two weeks at 9AM UTC and convert back to my local time zone it will be wrong when I hit change DST. But if I instead store the (datetime, zone) pair when I say "1PM fourteen calendar days from now in zone" it will always be correct. The UTC "trick" only works when your problem domain is representing specific moments in time.
- smitty1e 3y agoAnd how can you predict timezones policy changes in the future?
- autarch 3y agoYou can't, but if you store a datetime with an IANA time zone, then when the IANA time zone database is updated because of a DST change, your stored datetime is still correct.