How can I handle time zones in my webapp?

Solution 1:

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.

Solution 2:

In our applications, we generally store the time zone of the user when we first registers, as often seen on forum sites, and always display time with the time zone.

As for storing the dates, UTC is the way to go. Convert to UTC and stick it into the database. While retrieving, simply convert the time to the timezone set for the user.

I had to solve a similar use case, where customized notifications, like "Happy New Year", could be sent to all users of the web app. Since users are spread out world wide, we needed to display the notification according to the timezone. Storing timestamp in UTC nicely served our purpose, without hiccups.

In your use case, if you're not storing the user timezone somewhere you'll never be able to accurately return your search results without asking for user input, unless you start using some sort of location detection like gmaps does, but that isn't reliable. So you'll need to ask for timezone every time to make sure the user knows what he is entering in the website.

If you do have timezone information, the entire web app should be run with the timezone setting. Hence when the user does search for 9:00, he'll be searching with the Sydney timezone. On the other hand, if he creates an event while sitting in New York, he'll create an event with the Sydney timezone. We solve such cases by always displaying timezone while displaying dates.

Hope it helps! :)