How can I handle time zones in my webapp?

Aaron Digulla picture Aaron Digulla · May 31, 2012 · Viewed 36.3k times · Source

I'm looking for better understanding of the following user story:

John works in Sidney. At 9:00 in the morning, he logs an event in a web app that runs on a server in Zurich. The next day, he travels to New York for an emergency meeting in which the event should be discussed. During the meeting, he searches for the event by date and time.

As I see it, there are at least two issues here:

  1. How should I save the time stamps in the database
  2. How should I present them in the UI

When John searches the event, he will know that it happened at 9:00 but what should he enter in the web browser? He won't find anything when he just enters "9:00" as timestamp because that might be Zurich or New York time (since the event hasn't been found, the app has no way to know that it happened in Sidney, so it can't automatically select the correct time zone).

What is a good way to ask the user for a timestamp that might include the time zone?

The second issue is how to display the results. If teams from all over the globe need to discuss the event (and find related events, think of a cracker attack that targets several sites all over the globe at once).

What is a good example for displaying timestamps that might have been created in a different time zone?

Note: Please concentrate on the usability of the requirement. I can figure out the database mapping myself. Currently, I'm unsure about the work flow. It should ask/present the necessary information in an non-intrusive/intuitive way. If you can, give a link to an existing web app which already solves this.

Answer

Niet the Dark Absol picture Niet the Dark Absol · Jun 7, 2012

The issue of storing timestamps is simple: Store them in UTC.

As for displaying them, it would make sense to take the device's timezone setting and use that as the current timezone. That said, there should be a timezone dropdown next to the "time input" box, which defaults to the device's current timezone, so the user can change it if needed.

The majority of your users probably will not change timezones much, or at all. For the most part, the situation you outlined is uncommon. By implementing a dropdown with a suitable default, you should be able to make things easy enough for those who do move around (because they typically have a better understanding of timezones than a non-traveller would).

In fact, even better would be to save the timezone the device was set to when your app was first run, and then see if it ever changes. If it does change, then the user is probably a traveller and would probably benefit from having the timezone dropdown. Otherwise, just don't show the dropdown and default to the device timezone (because the user doesn't need to know about them). In either case, have a setting in the app that allows the user to manually show/hide the timezone dropdown.


To summarise the above:

  • On first run, save what timezone the device is set to.
  • Use that timezone as the default timezone. Always assume that timezone.
  • Should the device switch timezones, add a dropdown to select which timezone the event is in, defaulting to the device's own timezone.
  • Add an option to show/hide this timezone dropdown manually.
  • Always store timestamps in UTC.