How to properly support timezones in a mobile calendar app.

July 30, 2015

The earth is divided in timezones. Timezones guarantee that on every place on earth noon 12 o'clock is, roughly speaking, the middle of the day, when the sun is at its highest point on the firmament. As a result, 12 o'clock in one timezone corresponds to 11 o'clock one timezone to the west (the sun rises there later) and corresponds to 1 o'clock one timezone to the east (where the sun rises earlier). Most mobile calendar apps support timezones. In fact many calendar apps do not even allow you to create an event without specifying a timezone. But they do so in a totally unusable way. Thing is: you only notice when you start traveling...

Typically, if you create an event, the start and end time are labeled with the current timezone (and can be edited if needed). If you take your phone with you on a trip, and enter a region with a different timezone, most phones automatically determine the current timezone, and change it on the phone. As a result your phone displays the local time correctly. (Otherwise you would have to adjust the time on your phone manually, or adjust the timezone manually.) But there is a nasty side effect. Suddenly all your appointments on your mobile calendar are shifted! Why? Well, the timezone associated with them now is different from the local timezone the device is in. From the calendar app's perspective this makes sense. An event that takes place at 2 o'clock Amsterdam time, takes place at 1 o'clock in London time, and should be displayed to start at 1 o'clock when in London.

But from the user perspective this doesn't make sense at all. Users don't expect the time of an event to change. Suppose you are planning a trip abroad, and enter a train trip in your calendar. If you forget to properly set the timezone for that event, the time for the train trip will have shifted once you are abroad. As a result you will arrive a few hours too early (or a few hours too late) at the train station.

Some apps (Calvetica for example) try to remedy this by distinguishing device timezone and calendar timezone. By setting the calendar timezone, all events are displayed as if your device is in that timezone. I typically use that as follows: I set the calendar timezone to my home timezone, and whenever I am abroad, adjust my device timezone to whatever the local timezone is. All my events are created using my home timezone as the default. This way my phone displays local time, and my calendar appointments still show the time I expect them to show.

But this really is the wrong approach, because it effectively removes the benefit of specifying timezones in the first place. All events are displayed as if your device is in the calendar timezone. If for some events, timezone actually does matter, too bad.… (I missed a funding deadline back home because of this once, while I was visiting New York...)

So, what is the right approach?

Dead simple. Only use timezones for events where they matter. There are very few of them (see below). By default create events without labeling the start and end time with a timezone, and always display these timezone-less events in the calendar using the specified times (irrespective of the device timezone).

Why does this work in practice? The reason is that for most people, timezones are irrelevant. Most events take place at a fixed physical location. Therefore, events and their attendees are by definition always in the same timezone. (This is why, by default, most calendar apps use the device timezone as the default to use when creating events. Some even hide the timezone from the user.)

This is also true for people traveling. When abroad, your events there happen in a different timezone, but it is still the same timezone you are in. Setting no timezone even makes sense for the start and end time of (transatlantic) flights. And yes, for very short flights that cross a timezone, this means the end time of the event may lie before the start time! Something to be aware of when designing a calendar app...

The only other alternative would be to create an event for such a flight with a start time in the departure timezone and an end time in the arrival timezone. This is cumbersome of course, and not all apps allow it. It is also confusing, because when you open your calendar app after your smart phone has updated its timezone, the departure time for the flight you just disembarked from is different from what you remember when boarding. But this way at least the start time of the return flight is shown in local time on your calendar, so that you do not miss the flight back home (this almost happened to me once...).

You may now wonder: do timezones make sense at all? Is there any case, any type of event, where you'd want to use them?

In fact there is: virtual meetings, like teleconferences, or TV broadcasts, or phone calls with your summer holiday love. To be precise: virtual meetings where the audience is (possibly) attending from different timezones. In that case it makes sense to agree on a time for the meeting in a particular timezone. For all attendees the actual meeting time in their own timezone automatically appears when displaying the event in their own calendar app. It even adjust when they travel, so they are still able to connect with the virtual meeting on the right time.

Such virtual meetings (with attendees from different timezones) are rare though. So by default, calendar apps should simply create events without timezones.

Some physical events can become virtual for certain people, if they are abroad but want to remember to think about the event at the right time. E.g. parents wanting to call their child just before an important occasion.

Interestingly, for virtual meetings the start and end time are both specified using the same timezone. So it appears there is no use case for events that allow different timezones for the start and end time. Or am I missing something?

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Hans de Zwart
, 2015-07-30 10:21:28
(reply)

I am not sure I think you solution is the best one (at least not for everybody). What happens when I schedule a meeting in my home country and will have to take that call from a country in a different timezone?

I think I would prefer work with location. I would choose a default location for my calendar. If I don’t put a location in with the time, then it is assumed to be at that time in that timezone. If I add a location then it will know to adjust the timezone (internally accordingly). For the display I can then choose from which location I would like to view the times…

The best solution would be to get rid of this idea to match the apex of the sun with 12:00 at a particular place. Instead we should switch to Swatch Internet Time. I’ve written this comment @458.

admin
, 2015-07-30 12:03:20
(reply)

The example you give, of scheduling a meeting in your home country and to take that call from a country in a different timezone, is what I describe as a virtual event, for which timezones are relevant. My point is that such events are rare, and if you schedule them you are aware of the fact that you will have to deal with timezone issues.

In your proposal you use location instead of timezone, but the same problems remain. Yes, if you add a location for an event the times for the event are labeled automatically with the timezone corresponding to that location, so that simplifies matters a bit (you have to make sure that you enter the location exact enough for this to work though). As a result it will automatically show in your calendar at the correct local time. However, events in different timezones show differently in your calendar depending on in which timezone you are. For me at least this is confusing.

And how would you schedule an event, say a transatlantic flight, that starts in one timezone and ends in another? Which location should be used for such events? Or should there be two locations, one for the start location and one for the end location? (Personally, I prefer to see those events in my calendar showing the start and end time as local time, so that I know when to board, and I know at what time locally I will get off the plane. But maybe that is just a weird personal preference…)

What I propose is in a way very similar to Swatch Internet Time in that for the average user, timezones are irrelevant: he simply schedules all events according to local time (whatever that is). The advantage of Swatch Internet Time is that there is global agreement what time it is. I.e. there is no difference in local and global time.

Dave
, 2015-09-27 17:45:49
(reply)

I missed a flight last week due to this “feature.” How hard would it be to have a choice of how I want to use my calendar. I would prefer to have it work like a paper calendar, give me back EXACTLY what I put in no matter where I am in the world. I also use the cloud, two macs, an iPhone, an iPad, and connect with a co-workers calendar. One can, when setting things up on the Mac, choose “floating” to accomplish this, on the mac. There’s no “floating” choice in iOS, however, that I could find. Damn.