Storing date, time, and timezone for future events
Tantek recently published a blog post encouraging developers to use UTC with timezone offsets for storing dates and times.
There is, however, an unfortunate nuance his post doesn’t include, and so I’m pointing it out here.
For “when did this happen?” and “what time is it now?”, UTC, or UTC+offset, is perfect. Past events can be ordered easily.
However, for future events, “when will this happen?” it is, strictly speaking, incorrect. The (main) reason is that timezone offsets are not fixed, and do change. Not only do Daylight Saving Time (a.k.a. Summer Time, DST) policies impact the timezone offset (not to mention the existence of certain times, e.g. 2016-03-13T07:15:00-05:00 exists, but 2016-03-13T02:15:00 (America/New York) does not) but those policies can and do change.
- Chile abolished DST in 2015 (and apparently changed their plan as late as Jaunary).
- Russia did, too last year.
- Haiti started observing DST in 2013.
- A number of US states are considering abolishing it. (How serious they are is, of course, up for debate.)
This is why the W3C explicitly says “at a minimum you will need the time zone, not merely an offset from UTC” for future events.
Admittedly, as Tantek points out, these changes don’t happen that often. We disagree, though, whether that infrequency makes it worth knowing about.
Time is incredibly hard to do right. You have limited engineering time. Maybe given the requirements of your application or users, you want—or need—to choose not to worry about future changes to timezone offsets. But it’s important to be aware and make an informed decision, especially because if you only store the offset, you won’t have enough information to make the necessary updates when a change like this does happen.
It’s complicated, but @laut’s rule of thumb is a decent place to start.