4 ms·

I gave a talk last year about a timezone strategy for Rails apps (or any app really). Sadly it wasn't recorded, so I'm hoping I can give it again somewhere, but

I gave a talk last year about a timezone strategy for Rails apps (or any app really). Sadly it wasn't recorded, so I'm hoping I can give it again somewhere, but here are the slides and source: https://github.com/pjungwir/timezones-talk https://github.com/pjungwir/timezones-talk I suggest dealing internally with UTC as much as possible, and treating time zones as an "I/O formatting" concern. But ironically the big exception I know of is scheduling future events in calendars! The reason it's a problem there is that if you schedule a meeting, the app converts it to UTC, and then the timezone rules change, your meeting will be at the wrong instant. So it is important to keep the original input string (or at least the originally requested local time). Another crazy timezone issue I encountered recently is that the Javascript standard originally told browsers to use Daylight Savings Time transition dates from the current year when deciding the timezone offset of days in past years. This has been changed, but in IE you still see the old behavior. [1] is a Stack Overflow answer+comments that mention this history. You can see the problem by loading [2] in multiple browsers. The fix is to use moment-timezone.js [3]---but make sure you download the file with historical data! I guess the moral is that timezones are not easy. :-) [1] http://stackoverflow.com/questions/16946002/javascript-time-zone-is-wrong-for-past-daylight-saving-time-transition-rules http://stackoverflow.com/questions/16946002/javascript-time-... [2] http://jsbin.com/zicomitoka/edit?html,js,output http://jsbin.com/zicomitoka/edit?html,js,output [3] http://momentjs.com/timezone/ http://momentjs.com/timezone/

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.

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.