Blogs

RedMonk

Skip to content

The Problem with Time and Time Zones

Old Clock in Detroit Airport

Of late, I’ve come across several people talking about the trouble with living and working in multiple time zones. OK, more working than living:

  1. Anne with some tips on dealing with time zone dementia.
  2. Kaj on multi-time zone meeting etiquette.
  3. Working in multipule time zones as a key driver for “extreme jobs,” i.e., unsustainable, yet highly rewarding work schedules.
  4. Cory Doctorow’s Eastern Standard Tribe, a sci-fi book who’s core-concept is living and working in multiple time zones.

Far From a Solved Problem

Until I started to work at RedMonk, I really only worked in one time zone, CST. Now I have to sort out and work with several time zones a day: all of the US time zones and GMT.

In doing so, I’ve discovered that the software world is about half done internalizing best practices when it comes to time and time zones. Indeed, back when I worked on SaaS applications, we were plagued with time zone issues, esp. when day light savings came on.

Supporting Time Zones

There are three stages of “time zone support” in software:

  1. Allowing users to set their own time zones. For example, one user could set their time zone as CST, while another could set it as GMT. (A slight variation on this is allowing users to switch their time zones willy-nilly without effecting old data.)
  2. Allowing users to set a time zone on any given time. For example, when adding an event in a calendar, you can specify EST.
  3. Properly handling time zone conversions and integration with third party systems.

In my experience, most applications do the first fine. Allowing for the second is hit or miss (iCal has it, GCal doesn’t), and very few applications accomplish the 3rd.

The third is the one I get bitten by the most often. There’s some sort of bug in the otherwise fantastic Zimbra iSync plugin which messes up a meeting’s time zone if you edit the event in both iCal and Zimbra. As Anne suggested, the defensive user tactic for such situation is to put the actual time and time zone in the meeting title.

The General Principal

My personal bug reports aside, the general principal to draw from this is to make sure your applications truly have the 3 stages of time zone support above. As we move closer to the Eastern Standard World of work (for better or worse), software that doesn’t support not only a user’s time zone, but proper interchange of that time zone will be ignored by the time zone tribes.

Languages like Java, with the notorious pair of java.util.Calander and java.util.Date, took a long time to get time zone handling done well and it’s still hard to handle them in a fail-safe way. That said, investing time in figuring out time zone handling, QA’ing for it, and making sure to require it will pay off now and in the future.

Disclaimer: Sun is a client.

Technorati Tags: , , , , ,

Categories: Java, Programming.

Comment Feed

3 Responses

  1. Coté,

    Interning at Microsoft Office's Outlook group, I was tasked with looking at time zone issues. So time zones have been on my mind for some time.

    Previous Outlook support for your #1 was haphazard, at best. I wrote up the spec for #2 which has made its appearance in the recently released Outlook 2007. And Outlook, of course, is tightly integrated with Exchange but implements #3 with better support for iCalendar sharing in the latest release.

    I claim there is a 4th stage to time zone support in software. It can be summarized by the concept of "Journey Events". This special class of calendar items gives context for other calendar items. Imagine being able to visualize on a calendar when you will be in certain time zones or sharing that information with others so they can select better meeting times. So the 4th stage is like the 1st but with time/space parameters. This opens software up to a whole new set of features.

    Brandon

  2. Thanks for the Outlook update, Brandon!

    You're absolutely right about the 4th item if I understand it correctly: that is, being able to use time zones as a sort of filter/dimension/pivot to view not only your events, but the events of others and aggregations of events across people and time zones.

    As a side note: one interesting thing I've noticed on airline tickets is that they always display the time with the local time zone. That is, take off time will be in CST, while landing time will be in EST. That makes perfect sense for that application and it makes me wonder if there's a general principal (aside from "be smart" ;>) to extract from it.

  3. Cote-

    Thank you for the feedback. We were able to reproduce this issue on our side as well. We have created a bug and you can track it here: http://bugzilla.zimbra.com/show_bug.cgi?id=13523. Hopefully, we can get it fixed and into a patch soon.

    -jr

    John RobbJanuary 8, 2007 @ 7:18 am