Article summary
If your project involves timestamps, at some point, you will likely have to decide how to handle time zones. It can be tempting to put it off until it becomes a problem, but by that point, it may be too late! Fortunately, with some careful planning, it is possible to minimize the trouble caused by time zone complications.
Defining Time Zones
To understand this, you need to consider two separate concepts:
- A time zone is a region of the world where everyone observes the same standard time. It may be referred to by a more general name (e.g. “Eastern Time”) or by a country/city combination (e.g. “America/New York”).
- A time offset is the number of hours the observed time in any area differs from a standard reference point. On Earth, that standard reference point is known as Coordinated Universal Time (UTC)–or sometimes Greenwich Mean Time (GMT), which is basically the same thing. A time offset designates the number of hours behind (e.g. GMT-05:00) or ahead (e.g. GMT+06:00) of the reference time. So time offsets are just like the units on a measurement.
The DST Wrinkle
If it ended there, time zones would probably be no big deal. But unfortunately, Daylight Saving Time (DST) exists. DST causes some time offsets to change based on the date. So it is not sufficient to simply say “Eastern Time.” You must also distinguish between “Eastern Standard Time” (GMT-05:00) and “Eastern Daylight Time” (GMT-04:00), etc.
If handling timestamps in your application is going to break anywhere, it will likely be around the transition to or from Daylight Saving Time. To add to the confusion, the rules regarding the start and end times of DST have changed over the years.
Time Zone Strategies
A few strategies will go a long way toward managing time zones.
1. Store all timestamps using UTC.
As you might expect, it would be a lot easier if we didn’t have to deal with time offsets at all. It’s impossible to avoid them entirely, but many issues can be avoided by converting all timestamps to UTC as soon as possible (e.g. when processing input from a user), and converting them back to a local time as late as possible (e.g. just before presenting to the user). Timestamps should remain in UTC as long as they’re in a database or being passed among internal components.
2. Always use a library to perform date and time math.
Performing any kind of math or comparison on a timestamp by yourself is risky. Even something as seemingly innocuous as adding 86,400 seconds (24 hours) to a timestamp in order to advance it by one day will break on a DST boundary. DST rules change. Leap years are a thing (leap seconds are a thing). For these and many other reasons, always recruit a date/time library to help with calculations or comparisons. And even when using a library, be careful to note which time zone is in effect, as many will default to using the current local time zone if not specified.
3. Use a standard time offset.
Even if you store timestamps using UTC, you may want to designate an official time offset for your application. Most users will want to see times in their own local time zone, but internal business-related things might not need this. I have seen reporting software where calculations differ based solely on the time of the year a report is generated. (Why? Using the user’s local time zone allowed the time offset to change based on Daylight Saving Time.)
Conclusion
Handling time zones has the potential to drive you insane. By taking a proactive approach and using these strategies to manage them upfront, I hope you can keep your sanity!