The Biannual Timezone Wobble in Review

As posted on this blog many times before: Daylight Saving Time is a nightmare for computer systems. Where possible, computer systems must be moved to UTC, and the cases where local timezone calls must be made handled with extreme care.

• Problem: On two random Sundays, the local timezone might jump from 01:59 to 03:00, skipping an hour, or backtrack from 01:59 to 01:00, repeating an hour. Depending on the timezone, or other whims of the powers that be, this time might be different, or not at all.

  Solutions: use UTC where possible for scheduling jobs (for example, with crond on Unix). Document the time wobble, and audit the job schedules twice a year to ensure problematic jobs have not been added since the previous audit. Avoid running one-off jobs between 01:00 and 03:00 on Sunday, or add sanity checking to the jobs, so that they can be run multiple times though the AM hours. That is, run a job at 01:15, 02:15, and 03:15, and cache the last run time, so that the subsequent jobs will not run if the script has successfully run inside the last N hours.

• Problem: Date handling code is difficult to implement due to the complexities of Daylight Saving Time rules—not to mention leap years, leap seconds, and other complications, such as politicians randomly changing when the timezone wobbles.

  Solutions: again, use UTC where possible. Also, use standard libraries, instead of home grown code, as these libraries tend to accumulate more fixes and better handling of edge cases. Ensure unit tests exist at minimum for the various known edge cases, such as leap years, or for when the definition of the timezone changes.

• Problem: migrating to UTC is difficult.

  Changing the timezone will require a careful review of the systems, software, and documentation. A timezone change can have ramifications for logging, monitoring, upstream and downstream systems (that might assume a particular timezone, or pass data without a timezone), and perhaps also with any database systems involved. Test the changes carefully, and coordinate with all known client and peer systems.

Using a local timezone is an easy mistake to make. Correcting the mistake to UTC will be time consuming and costly. Not correcting the mistake of using a local timezone will also be time consuming and costly. Is a fire drill (at best) or disaster (at worst) twice per year, every year, more or less expensive than simply migrating away from timezone that wobble?

Technorati Tags: computers, cron