4 ms·

This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. If I needed to define a daily alarm

by praash 3y ago

This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.

pasc1878 3y ago
You need to know more than that. Is the appoint meant 2pm in London or in New York. So for forward times you need a location as well as the date and time. Yes when it happens you store in UTC. In both cases you can display to user with local timezone. (Although if the London user is going top fly to NY they will still want to see the NY time and not their local time)
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 ago
  Thank 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 ago
  And how can you predict timezones policy changes in the future?
  - autarch 3y ago
    You 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.

by praash 3y ago

pasc1878 3y ago

You need to know more than that. Is the appoint meant 2pm in London or in New York. So for forward times you need a location as well as the date and time. Yes when it happens you store in UTC. In both cases you can display to user with local timezone. (Although if the London user is going top fly to NY they will still want to see the NY time and not their local time)

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 ago
Thank 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 ago
And how can you predict timezones policy changes in the future?
- autarch 3y ago
  You 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.