If I normally work in Boston, and Jim normally works in San Jose, and Rachel normally works in Austin, we live in three different time zones. When we talk to each other pairwise, and cite specific times to each other, we have to be careful to avoid confusion. I might decide, for example, to always quote my times in the Eastern time zone. And I might even be careful about saying so: "I'll call you at 10 Eastern." When I'm talking to Rachel, she has to subtract two hours to figure out whether 10 Eastern works for her. I have to remember to say "Eastern" and Rachel has to hear it, and remember that Eastern is two hours ahead of her (not behind). If we both do everything right, all is well. Then she has to shift gears when she talks to Jim, because he's in Pacific.
Adopting a convention about how project team members quote times to each other reduces the chances of confusion. If a project team can pick a time zone that will be the project's time zone, and they always cite times in that time zone, life is easier.
There isn't much chance of confusion about time zones in email headers or in software, because most software is aware of the issue and can present times in a variety of formats. The real problem happens in verbal communication and in text that we type into documents and messages. So let's look at how adopting a "Project Time" can save you trouble and reduce confusion.
What is "Project Time"?
"Project Time" is the conventional time zone that everyone agrees to use when communicating with project team members. For example, if most of the team is based in the Central Time Zone, it would make sense to quote all times in Central Time. This does require that everyone learn how to convert back and forth between Central Time and the zone they're in. But that's all they have to learn. Since nobody ever quotes a time in Eastern Time, somebody who lives in the Pacific Time Zone will never have to make a conversion from Eastern to Pacific. If you travel to another time zone away from your home base, you'll have to start to make conversions between Central Time and your temporary base. But that's your responsibility — nobody else's.
Having a Project Time helps you avoid having to know where everyone else is, and knowing how to convert the times they quote. All you have to know is where you are. And nobody else has to know where you are. All they have to know is where they are.
Glitches are still possible, even when you decide to have a Project Time. For example, sometimes people work on two or more projects. One project might decide to use Central Time, and another might decide to use Pacific Time. When this happens, the people who work on both projects have to keep straight which is which. To avoid this problem, quote project time by its real name, rather than as "project time." For example, if Project Time is Pacific, say "The conference call is at 10 am Pacific Time," rather than "The conference call is at 10 am Project Time." This makes it easier for people who work multiple projects.
What alternative approaches are there?
There are a few alternatives to Project Time:
- Always cite times in the listener's time zone, adding the name of the zone
- Always cite times in my own time zone, adding the name of the zone
If you use the listeners' time zones, you face several problems:
- There could be more than one listener, and they could be in different time zones. This can happen in a conference call. Which one do you choose?
- The listeners might not be at their own home bases. They could be visiting another time zone temporarily, and you might have to correct for that on the fly. Unless you're very, very good, you'll eventually make a mistake. And you have to keep track of what zone they're in, too.
- You might not know the listeners' time zones.
- You might think you know the listeners' time zones, but you could be mistaken.
- Some parts of the United States don't adopt Daylight time. Hawaii, Indiana, and Arizona are all quirky. See, for example, "Time in Indiana" and "Time in Arizona" at Wikipedia.
- If the team is international, you might not be familiar with everyone's time zones, and daylight savings time conventions vary around the world.
Using your own time zone instead is also problematic:
- You might not be in your home time zone.
- The listener might not know your time zone, so you have to remember to identify it.
- You put the responsibility on the listener to convert from whatever time zone you use to wherever they are, and to know what your daylight savings time conventions are. They might not know how to do that. After you cite a time, you can sometimes see them glaze over and lose the thread of the conversation as they punch the calculation into their mental calculators.
Both of these approaches are more likely to lead to confusion than using Project Time.
What is Zulu time?
The US Military has had to deal with this same problem for many years. They long ago adopted what they call "Zulu" time. Essentially, Zulu is the time at 0° of longitude, at the Royal Naval Observatory in Greenwich, UK. Zulu time is actually a time called Universal Time (UTC), if you're interested in the technicalities. If your team is international, and especially if you work with the military or if your team spans the prime meridian, Zulu time is a good choice for Project Time. But if nobody on your team actually uses Zulu, it's probably better to pick the time zone that most people use.
Questions, suggestions, experiences to share? Nightmare stories you'd like me to add to this essay? Contact me to discuss your specific situation, by email at rbrenxhRICBqXeoyolqipner@ChacqOMWlrDJNuAlDFLooCanyon.com or by telephone at (617) 491-6289, or toll-free at (866) 378-5470 in the continental US.