4 ms·

I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa chang

I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant) Samoa changes the rules. The calendar doesn't change. This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

achamayou 10y ago
Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't). School times, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.
- deleted 10y ago
  [deleted]
masklinn 10y ago
> You want a meeting at 1100 local time. On a specific day. > The calendar doesn't change. Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time). > This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify. * while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local * this is stored as 2012-01-05T22:00:00+0000 * tzinfo gets updated with Pacific/Apia at UTC+13 * your calendar now tells you your meeting is on January 6th at 11 local * you're a day late
- mjevans 10y ago
  You're both correct. The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick. P) The event is at a precise internationally recognized moment (better for co-ordination globally). R) The event is in local time (like a lunch date) and expected to remain colloquially fixed. In the case of the first you store a precise UTC timestamp and drop the timezone (it's UTC). In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.
tedunangst 10y ago
Samoa did change the calendar. The local <-> utc mapping changed. In order to update the stored database, you need to convert all times to local with the old mapping, then convert to utc again with the new mapping.

achamayou 10y ago

Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't). School times, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.

deleted 10y ago
[deleted]

masklinn 10y ago

> You want a meeting at 1100 local time. On a specific day. > The calendar doesn't change. Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time). > This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify. * while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local * this is stored as 2012-01-05T22:00:00+0000 * tzinfo gets updated with Pacific/Apia at UTC+13 * your calendar now tells you your meeting is on January 6th at 11 local * you're a day late

mjevans 10y ago
You're both correct. The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick. P) The event is at a precise internationally recognized moment (better for co-ordination globally). R) The event is in local time (like a lunch date) and expected to remain colloquially fixed. In the case of the first you store a precise UTC timestamp and drop the timezone (it's UTC). In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.

tedunangst 10y ago

Samoa did change the calendar. The local <-> utc mapping changed. In order to update the stored database, you need to convert all times to local with the old mapping, then convert to utc again with the new mapping.