Communicating Timezones

When working internationally, methods that were barely sufficient in a national context become untenable.

In this post, I want to talk about timezones, which are surprisingly hard already. But there’s one practice in communication that makes them so much harder that they need to be.

Luckily the solution is really easy.

• The problem
• Abbreviations are almost never as unique as you think
• Almost EVERYONE gets them wrong half the time
• Abbreviations rely on the recipients having memorised the offsets
• Doing it better
• Communicating proactively
• Who looks it up
• Use UTC/GMT/Zulu
• Use 24 hour time
• When you need to use the abbreviation, add the link
• Create a calendar entry
• Other tools
• Coping with sloppy communication
• Summary

Communicating timezones using their abbreviations (Eg BST, NZDT, CST, IST) is ambiguous and puts unnecessary load on the reader to guess what you mean.

Above: The duplicates of some commonly used timezone abbreviations.

In the above screenshot, I’ve run through a few timezone abbreviations. Notice how in most cases, all of the duplicates are likely in a conversation within an international company.

Also notice how wildly different the times are in each case.

It might seem obvious to you which one you mean. To an international recipient, it almost never is.

It might be tempting to direct co-workers to a list of acronym definitions on the company intranet. Assuming that the appropriate entry has all of the required information (which timezone it is, UTC offset etc); now the recipient is taken out of the message that you are trying to convey, and the context switch has broken the understanding that you were trying to convey.

When daylight savings changes, the timezone abbreviation changes. Yet I’ve regularly seen people still using the old abbreviation, or simply using the same abbreviation all year around, yet expecting the recipients to know that daylight savings has changed their region.

Let’s break a couple of assumptions:

• Daylight savings changes occur on different dates in different countries around the world. Ie we don’t all change at the same time.
• Some countries don’t observe daylight savings time, so don’t change their clocks at all.
• The northern and southern hemispheres change in opposing directions because their seasons are offset by half a year.

Assuming that you’ve solved the all of the ambiguity above, readers still have to know the offsets before they even begin to think about how it applies to them. This is an unnecessary level of abstraction that takes them out of the message that you are trying to convey.

If they don’t know the timezone you mean, they have to look it up. Again, taking them out of the message that you are trying to convey.

Remember that it’s more expensive for multiple people to look something up than for one person to look it up.

And every person who needs to look it up, is another place in which mistakes can happen. So if the reader has to look it up, that massively increases the chances of failed communication.

Therefore the burden to look it up and provide appropriate links for context should almost always fall on the writer.

UTC, GMT, and Zulu are not exactly the same. But they are for these purposes.

Use UTC offsets. Eg instead of saying PDT, say UTC-7.

I’ve met one person who says that we should all use Zulu (without the offsets). I wouldn’t go this far for normal communication, but there are cases (such as when doing a post-mortem for a Cloud Infrastructure Outage) where it makes things so much easier.

But, some people may not know their own offset to compare the others to, right? They also won’t know their timezone abbreviation until they’ve learnt it. So they have to learn one sooner or later. They may as well learn the one that leads to clear communication.

Use 24 hour time. 12 hour AM/PM only creates another layer of translation/calculation that the reader needs to do.

If you do need use 12 hour time; never, ever leave off the AM/PM. It is never obvious what you mean in an international setting.

If you find a use-case where communicating the abbreviation is the best solution (I can’t imagine what this use-case could be), make sure to link to the intended timezone on every, single, occurence. Eg:

CST vs CST vs CST.

I like timeanddate.com, but there are many others that are likely to be just as good.

When possible, create a calendar entry that people can see on their own calendars. In my experience, this has caught a huge number of miss-communications. Both, my own, and other peoples’.

When the communication medium is something like email, I like timeanddate.com’s meeting planner. But there are also some really good tools that can interact with your calendar and allow people to book a slot based on your availability. Their timezone handling was hilariously bad in the early days, but they usually do an excellent job now.

Sometimes you’re simply going to receive sloppy communication. For that, I’ve created the timezone2offset project. It doesn’t fix the problem, but it does make it faster to narrow down what they mean. It can also be used to help you choose the right offset when writing communication for other people.

Above: Demoing a few timezone examples.

There’s so much more that timezone2offset can do, so that will have to be another post. In the mean time, the project page gives you a pretty good idea about what it can do.

I’ve used a lot of “never”, “ever”, and “always” in this post. I try not to do that, but it really is called for in this case.

Clear communication is quick to understand, and reduces the stress and burden on the reader.

UTC offsets (eg UTC-8) achieve that. Timezone abbreviations (eg PST) don’t.