This talk was presented in Atlanta at RailsConf 2015.
Abstract:
For developers, there are two things that are certain for time zones: you can’t avoid having to deal with them, and you will screw them up at some point. There are, however, some ways to mitigate the pain. This talk will discuss tactics for avoiding time zone mayhem, using a feature to send out weekly email reports in a customer’s local time zone as a case study. It will cover idiosyncrasies of how time zones are handled in Ruby and Rails, how to write tests to avoid false positives, and advice on how to release time zone-related code changes more safely.
Abstract:
For developers, there are two things that are certain for time zones: you can’t avoid having to deal with them, and you will screw them up at some point. There are, however, some ways to mitigate the pain. This talk will discuss tactics for avoiding time zone mayhem, using a feature to send out weekly email reports in a customer’s local time zone as a case study. It will cover idiosyncrasies of how time zones are handled in Ruby and Rails, how to write tests to avoid false positives, and advice on how to release time zone-related code changes more safely.
Response to my talk, on Storify.
Testing checklist:
- covering time zones west/east of UTC
- pin down exactly when you’re starting and when you’re ending
- pick random dates in the past or in the future--not current dates
- test dates inside/outside daylight saving period
- check that the dates being used in your tests are the expected day of the week
- test when triggering the scripts on different days of the week
- test on dates of daylight saving transitions
Lessons:
- Trust NOTHING
- Have a backup plan
- Do an internal test run
- Today’s console results are not tomorrow’s console results
- Guard against writing false positive tests
- Figure out a consistent, global logic
Code: