How can I handle time zones in my webapp?

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.

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.

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! :)

1. UTC. Keep it simple.

2. Use the timezone that is most relevant to the user.

If you know the user is going to be in or travelling to Sydney for the event, then they will be thinking in that timezone when arranging transport to the event. The fact that they're currently in New York is largely irrelevant. And of course, if your app shows dates in a variety of timezones, it should always show the timezone next to the date, e.g. 09:00 EST.

If it doesn't clutter your interface too much, you could display dates in the event timezone and local timezone, e.g. 2012-06-13 09:00 EST (2012-06-12 19:00 EDT).

I would argue that searching is a similar problem, with one caveat: we can tolerate false positives (getting a result we weren't expecting), but we can't stand false negatives (not getting a result we were expecting).

Again, I'd focus on searching the most relevant timezone to the user (e.g. event timezone), and give these results priority in the search results, but you can also return events that match in other timezones that are relevant to the user (e.g. local time). If you do this, you should show the event date in the matching timezone, especially if you highlight matching text.

Here I'm giving suggestions for best usability without bothering much about implementation feasibility.

1. For first issue of storing events in db, everybody would agree to store it in UTC
   
   
2. To give the best user experience, save the history of timezone of user. If you could save timestamp of time zone change, even better. This will enable us to give freedom to user to query without specifying timezone explicitly each time.
   

> So with these features, let see how search query of just "9.00" by > John will be handled:
With above mentioned features, now I know > that John has been in 2 timezones till date(or get timezones list for > mentioned period) . So I'll covert 9.00 from Sydney time zone to UTC, > fire a query. Also convert 9.00 from NewYork time zone to UTC, fire a > query. In result I'll show 2 rows to John displaying what he did at > 9.00 in sydney and at 9.00 in new york. New york line will be blank in this case, but I think still should be shown to user , just to inform > him that we searched for this time zone too.

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

> If his timezone is recently changed, whenever he logs in application, > a notification should be given that, your default timezone is changed > to native timezone.
While creating event, lets say user selects > timezone from drop down.Lets not burden user by giving options of all > timezones of world.First option of dropdown should be current time > zone of user's device. after that timezones from his history of > timezones, then UTC and then remaining timezones which he has never > used till date.

4.How to display the results, if teams from all over the globe need to discuss the event:

> I would like to divide this use case between number of teams 2 or more > than 2.
For just 2 teams, I would prefer that each team sees > timestamp in its local time zone and other team's time zone. (I > personally prefer to talk in timezone of person at other end for his > convenience while scheduling a meeting). For more than 2 teams, its > better to consider more common timezone i.e. UTC. So in this case, every > user should see timestamp in 2 timezones, in UTC and in his default > timezone.

These suggestion are given with intention that user need not do any calculation in his local time but at the same he should be able communicate with other users fluently in their preferred time zone.

Ok I got a different approach than others:

Firstly, I assumed few things before hand.

Person who is listing an event has smartphone(if it is a browser, I dont have to make these assumptions) with:

1. GPS

2. HTML5 capability.

3. Javascript capability

> How should I save the time stamps in the database?

Solution: Obviously UTC, I overlaid procedure below:

Step 1. Use the Geolocation of the user using the Geolocation API

    window.onload = getMyLocation;

    function getMyLocation() {
    	if (navigator.geolocation) {
    		navigator.geolocation.getCurrentPosition(displayLocation);
    	} else {
    		alert("Oops, no geolocation support");
    	}
    }
    
    function displayLocation(position) {
    	var latitude = position.coords.latitude;
    	var longitude = position.coords.longitude;
    	var div = document.getElementById("location");
    	div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

Step 2. Give the (Long,Lat) as arguements to some of the (Lat,Long) to TimeZone api's like the Yahoo API (use Flag R to get the Latitude converted to Timezone) to get the users timezone.

=> The users timezone is determined without user input ( I am using this because you cannot simply assume that user knows the timezone of place he lives in, I knew my timezone only after few months or something at the place :P, pretty dumb!)

The each Event table has Timezone, Event & so can also have CityName Then create another database table with classification based on CityNames. So here the user will have two columns

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________| 

> For UI

=> use Google Calendar API or some of the Calendar API's

Related Readings:

1. https://stackoverflow.com/questions/5584602/determine-timezone-from-latitude-longitude-without-using-web-services-like-geona

2. https://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude

I know its just about showing some idea how to solve this problem. But see how accurate & light-weight it becomes on users when the Timezone is determined by using device APIs

Hope it helps!

For that particular case I would store both local and UTC time. UTC is a somewhat major and used for sync and convertion of time to current time zone. Local is used for searches and for additional info, like:

You have a meeting:

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

or something like that. The other way is to store creation time zone, and convert at runtime (this is particularly better in case then user will change meeting time). Either way the main reason is to be able to restore original creation time so user can refer to it.

> 1. How should I save the time stamps in the database

At event creation, I would store UTC time and local time zone (aka creation time zone). I would use what I stored to convert UTC time into local time (aka creation time) and store it alongside UTC time and creation time zone.

NOTE: I can store local time from the get-go, but when the user does a search for an event, I would hope a conversion to local time exists. I also hope the server can detect which time zone the client is in.

> 2. How should I present them in the UI

When a user searches for "9:00", I would search for events that include "9:00" in either UTC OR creation time OR local time. For the results, I would display one table of results in creation time (This is intended to display timestamps that may have been created in a different time zone, as we assume the user is looking for what time he created an event for wherever he was.), and display a second table of results below with related results, perhaps with the header, "Not what you're looking for? See related results" (these include the leftover UTC and local time results).

Overall, I would display UTC time, the local time, the creation time, and the creation time zone (i.e. the local time and time zone of the event where it was created) sorted by UTC time, so you can see which event comes first, in case two different events were scheduled for 9:00 in two different time zones.