6 ms·

> If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day

by lhorie 7y ago

> If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day Not necessarily. If the event is a long distance meeting that span multiple timezones, then by definition, the event isn't going to be at 2pm for all consumers of that data. Location is kind of a proxy for timezone, but it makes more sense to just let the client's OS figure the offset from UTC time than to manually manage timezones in the server yourself. Similarly, you let the client tell the server what timestamp "2pm two weeks from now" is (letting it consult its OS' timezone database to figure out what that means for the user's chosen geographic location), rather than trying to naively add up the seconds from now to then in the server. Saving the user's location in your DB to compute offsets on the server is problematic because you can't always get geographic data from the client (e.g. browsers will readily make timezone available to Javascript, but geolocation data might be unobtainable due to permissions/privacy concerns/etc). Also, users may move/travel, so getting geo data from side channels such as sign up forms also could lead to discrepancies.

wvenable 7y ago
If you store UTC, you automatically get the result that meeting occurs at the same time for everyone. But you could also get the situation where, depending on timezone and DST changes, that 2:00pm meeting doesn't occur at 2:00pm for any of the participants! The problem is really far more difficult and interesting than just storing all dates as UTC as a rule.
- lhorie 7y ago
  AFAIK that can only happen if the the government changes the DST policy (or timezone) between the time the event was scheduled and the meeting date. Thankfully, DST policy changes are comparatively rare. And in actuality, even if the event doesn't happen at 2pm for the person who got affected by the DST policy change, it'll still be scheduled at the "expected" time for everyone else (unless they too get affected by a DST policy change as well). Also, most OSes are decent enough nowadays to update their timezone/DST databases regularly so that UIs that use UTC will reflect the discrepancy in future time intent soon after the policy change takes effect.
  - wvenable 7y ago
    If you convert a future date-time to UTC using the current timezone database you've already lost. If the timezone database changes anytime from that point forward, you cannot correctly convert that UTC date back to local time. You have no way of knowing, just looking at a UTC date, under what conditions it was converted from local time. By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes. > Thankfully, DST policy changes are comparatively rare. "Russia switched to permanent DST from 2011 to 2014, but the move proved unpopular...so the country switched permanently back to standard time in 2014... Florida legislature and Washington State Legislature passed bills to enact permanent DST, pending US Congressional approval, and California, Maine, Massachusetts, New Hampshire, and Rhode Island have introduced proposals or commissions to that effect... Under an EU directive, from 2021 twice-yearly adjustment of clocks will cease. Member states will have the option of observing either standard time or summer time all year round." -- Wikipedia
    - lhorie 7y ago
      You seem to be missing the forest for the trees. DST policy changes _are_ rare, compared to the millions of times when people schedule multi-timezone meetings, international flights, etc. Bursts of high frequency DST policy changes are so rare that they get articles written about them. > you cannot correctly convert that UTC date back to local time. Of course you can. It may not be the same local clock time with most implementations, sure, but it will still correctly point to the same physical time relative to the local times of everywhere else on Earth. It would be physically impossible to retroactively change the time of the meeting to account for the the DST policy change and maintain the same clock time for participants in other timezones, so something's gotta give. It's also not true that you can't recover the intended time after a DST policy change. Although it's monumentally laborious, it's definitely possible: you can keep track of the historical changes in the timezone database and work backwards from the UTC date and the date of that record change. > By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes. Sort of. The assumption there is that the time delta between now and then is smaller than the delta between a notice of policy change and the time it goes into effect. It is, however, technically an engineering trade-off. The trade-off here is that you can have a far simpler and almost-always correct implementation by taking a tiny risk of a discrepancy between intent and actual local time in the extremely rare occasion that a policy changes without advance notice. Responsible governments will typically give plenty of advance notice so timezone databases can be updated and clients can then correctly calculate future offsets since they will know how to account for the policy change. You could certainly forego UTC time and make an engineering decision of storing local clock time if your application matches a very strict set of timezone boxing requirements, but in my experience, it's more common that people pick this approach out of ignorance than careful analysis, and in some cases, it gets nasty to support when the requirements change (e.g. as soon as you have a new sales team office on the other side of the country)

by lhorie 7y ago

wvenable 7y ago

If you store UTC, you automatically get the result that meeting occurs at the same time for everyone. But you could also get the situation where, depending on timezone and DST changes, that 2:00pm meeting doesn't occur at 2:00pm for any of the participants! The problem is really far more difficult and interesting than just storing all dates as UTC as a rule.

lhorie 7y ago
AFAIK that can only happen if the the government changes the DST policy (or timezone) between the time the event was scheduled and the meeting date. Thankfully, DST policy changes are comparatively rare. And in actuality, even if the event doesn't happen at 2pm for the person who got affected by the DST policy change, it'll still be scheduled at the "expected" time for everyone else (unless they too get affected by a DST policy change as well). Also, most OSes are decent enough nowadays to update their timezone/DST databases regularly so that UIs that use UTC will reflect the discrepancy in future time intent soon after the policy change takes effect.
- wvenable 7y ago
  If you convert a future date-time to UTC using the current timezone database you've already lost. If the timezone database changes anytime from that point forward, you cannot correctly convert that UTC date back to local time. You have no way of knowing, just looking at a UTC date, under what conditions it was converted from local time. By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes. > Thankfully, DST policy changes are comparatively rare. "Russia switched to permanent DST from 2011 to 2014, but the move proved unpopular...so the country switched permanently back to standard time in 2014... Florida legislature and Washington State Legislature passed bills to enact permanent DST, pending US Congressional approval, and California, Maine, Massachusetts, New Hampshire, and Rhode Island have introduced proposals or commissions to that effect... Under an EU directive, from 2021 twice-yearly adjustment of clocks will cease. Member states will have the option of observing either standard time or summer time all year round." -- Wikipedia
  - lhorie 7y ago
    You seem to be missing the forest for the trees. DST policy changes _are_ rare, compared to the millions of times when people schedule multi-timezone meetings, international flights, etc. Bursts of high frequency DST policy changes are so rare that they get articles written about them. > you cannot correctly convert that UTC date back to local time. Of course you can. It may not be the same local clock time with most implementations, sure, but it will still correctly point to the same physical time relative to the local times of everywhere else on Earth. It would be physically impossible to retroactively change the time of the meeting to account for the the DST policy change and maintain the same clock time for participants in other timezones, so something's gotta give. It's also not true that you can't recover the intended time after a DST policy change. Although it's monumentally laborious, it's definitely possible: you can keep track of the historical changes in the timezone database and work backwards from the UTC date and the date of that record change. > By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes. Sort of. The assumption there is that the time delta between now and then is smaller than the delta between a notice of policy change and the time it goes into effect. It is, however, technically an engineering trade-off. The trade-off here is that you can have a far simpler and almost-always correct implementation by taking a tiny risk of a discrepancy between intent and actual local time in the extremely rare occasion that a policy changes without advance notice. Responsible governments will typically give plenty of advance notice so timezone databases can be updated and clients can then correctly calculate future offsets since they will know how to account for the policy change. You could certainly forego UTC time and make an engineering decision of storing local clock time if your application matches a very strict set of timezone boxing requirements, but in my experience, it's more common that people pick this approach out of ignorance than careful analysis, and in some cases, it gets nasty to support when the requirements change (e.g. as soon as you have a new sales team office on the other side of the country)