3 ms·

Following up because I need to write some time handling stuff in a side project. Could you elaborate on why a future date would cause a problem?

by foota 10y ago

pjungwir 10y ago
Sure! It is a rare problem, but I seem to recall a similar thing (at Facebook?) actually making the news not that long ago. Here are the steps: 1. The user in California saves a meeting at 7am for June 1, 2017. (Today is April 17.) 2. You convert to UTC (-0700) and save that in your database. 3. On May 1st California decides to stop observing Daylight Savings Time effective immediately. Your server automatically updates its system-wide timezone file so it knows about this change. Now that UTC date in your database is happening at 6am instead (-0800). The instant hasn't changed (The meeting is still happening at the same moment in e.g. Paris.) but the user probably really wants it to stay at 7am. They are going to be annoyed if their colleagues dial in while they are still in the shower. :-) I hope that helps!
- pjungwir 10y ago
  EDIT: jfoutz gives a much more realistic example: maybe California doesn't give up on DST altogether, but just moves the start date. Note this is not really about DST at all, but DST stories probably make the best examples. Another example could be that China decides to create East and West timezones.
- foota 10y ago
  That's extremely helpful, thanks!
deleted 10y ago
[deleted]
user5994461 10y ago
I assume because of daylight saving times. It will offset the conversion. Friday => UTC to local time is 7 hours. Monday => UTC to local time is 8 hours.
- foota 10y ago
  This is true, but that wouldn't affect the scheduled time of an event.
jfoutz 10y ago
Not the OP, but for example, the United States switched the day to start observing DST a few years ago. Individual states change their observation of DST from time to time. If you have an event scheduled for next year, and the rules change, do you need to modify the display of that event? How do you know which appointments on the calendar have been updated to follow the new rules? You have version 1 of your software, then the rules change, so you release version 2. That updates dates on first launch. You have an unrelated bug, and release version 3. what happens to users that upgrade from 1 to 3? Time handling has a bunch of funny edge cases anyway, even without DST. Those projects often end in tears.
defen 10y ago
An important concept to have in your mind when dealing with timezones is that "Time Zones" and "Zone Identifiers" are not the same thing. "Time Zones" refer to an offset from UTC used to compute the local time; "Zone Identifers" identify a geographic region that has political rules about what its current time zone is. For example, "America/New_York" is a standard identifier for a geographic area. Depending on the date, it is either 4 hours or 5 hours behind UTC. That is what we call daylight savings time, and it controls whether America/New_York uses the "Eastern Standard Time" (EST; GMT-5) or the "Eastern Daylight Time" (EDT; GMT-4) time zone. If those political rules change, and you threw away the local time zone info as it existed when the record was created (because your app converts everything to UTC) then users will get the wrong times for their events.

Following up because I need to write some time handling stuff in a side project. Could you elaborate on why a future date would cause a problem?

by foota 10y ago

Following up because I need to write some time handling stuff in a side project. Could you elaborate on why a future date would cause a problem?

pjungwir 10y ago

Sure! It is a rare problem, but I seem to recall a similar thing (at Facebook?) actually making the news not that long ago. Here are the steps: 1. The user in California saves a meeting at 7am for June 1, 2017. (Today is April 17.) 2. You convert to UTC (-0700) and save that in your database. 3. On May 1st California decides to stop observing Daylight Savings Time effective immediately. Your server automatically updates its system-wide timezone file so it knows about this change. Now that UTC date in your database is happening at 6am instead (-0800). The instant hasn't changed (The meeting is still happening at the same moment in e.g. Paris.) but the user probably really wants it to stay at 7am. They are going to be annoyed if their colleagues dial in while they are still in the shower. :-) I hope that helps!

pjungwir 10y ago
EDIT: jfoutz gives a much more realistic example: maybe California doesn't give up on DST altogether, but just moves the start date. Note this is not really about DST at all, but DST stories probably make the best examples. Another example could be that China decides to create East and West timezones.
foota 10y ago
That's extremely helpful, thanks!

deleted 10y ago

[deleted]

user5994461 10y ago

I assume because of daylight saving times. It will offset the conversion. Friday => UTC to local time is 7 hours. Monday => UTC to local time is 8 hours.

foota 10y ago
This is true, but that wouldn't affect the scheduled time of an event.

jfoutz 10y ago

Not the OP, but for example, the United States switched the day to start observing DST a few years ago. Individual states change their observation of DST from time to time. If you have an event scheduled for next year, and the rules change, do you need to modify the display of that event? How do you know which appointments on the calendar have been updated to follow the new rules? You have version 1 of your software, then the rules change, so you release version 2. That updates dates on first launch. You have an unrelated bug, and release version 3. what happens to users that upgrade from 1 to 3? Time handling has a bunch of funny edge cases anyway, even without DST. Those projects often end in tears.

defen 10y ago

An important concept to have in your mind when dealing with timezones is that "Time Zones" and "Zone Identifiers" are not the same thing. "Time Zones" refer to an offset from UTC used to compute the local time; "Zone Identifers" identify a geographic region that has political rules about what its current time zone is. For example, "America/New_York" is a standard identifier for a geographic area. Depending on the date, it is either 4 hours or 5 hours behind UTC. That is what we call daylight savings time, and it controls whether America/New_York uses the "Eastern Standard Time" (EST; GMT-5) or the "Eastern Daylight Time" (EDT; GMT-4) time zone. If those political rules change, and you threw away the local time zone info as it existed when the record was created (because your app converts everything to UTC) then users will get the wrong times for their events.