This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: The Problem with Time and Time Zones from PeopleOverProcess.com Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

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: time, timezones, est, work, bestpractices, redmonkadvice