Friday, May 9, 2014

Store dates and times using UTC

UTC is better because it's precise. Local time zones are ambiguous.

In the past, I've tended to avoid UTC and just use my local time zone for dates and times because troubleshooting was easier when I didn't have to convert time zones (for log entries, database tables, etc). This generally worked OK when I was working alone, and all my computers were set to my local time zone. However, I started noticing situations where time conversions were necessary, such as when I wanted to publish a website on a host server outside my time zone, or when I was working on a project with one or more developers in different time zones.

In these situations, I was already converting to one or more time zones, so converting to UTC should be, at worst, no more difficult, and at best, easier, since everyone converts to the same base time. I also noticed that converting between time zones actually became impossible in certain situations when dealing with Daylight Saving Time (DST).

  • When the local time 'falls back' at 2:00am, 1:30am has two valid values.
  • When the local time 'springs forward' at 2:00am, 2:30am has zero valid values.

I finally became a UTC convert when I was writing an application that needed to trigger alarms at specific times, and users were allowed to enter times in their local time zones. This was fine when everything was the same time zone, but it quickly became clear I was going to have issues with users outside my time zone.

  • Do I store alarm times in the user's time zone?
  • Do I store alarm times in a common time zone? Which one?
  • When I host this on a server will it still work on servers outside my time zone?
  • What if my server "springs forward"? Will it miss sending out alarms for that hour?

I solved all of these problems by storing the times in UTC, because UTC is UTC, regardless of time zones.

No comments:

Post a Comment