Get your timezones right

2021-06-21

I work with folks all around the world, so timezones are an omnipresent factor in communications. Like most people I've worked with, I like to be cognizant of the time of day for others and work with the differences for meetings and the like.

Also, as a very analytical nerd, I like precision, and that's especially necessary for timezones. So, in this not-really-a-rant, let me give you some advice, please.

First and most importantly: Daylight Saving Time matters. Yes, it's awful and should be abolished (or adopted all year, either way suits me). But, for now, it screws with our clocks and our minds, and when you are naming a timezone, sometimes you have to specify it.

DST on Wikipedia

For example, I am on the East Coast of the US.

When DST is in effect, my timezone is Eastern Daylight Time, or EDT.

When DST is not in effect, my timezone is Eastern Standard Time, or EST.

Yet, all year, people set meeting times in EST. So, while DST is in effect, does that mean that the meeting is actually an hour earlier than stated, or that it is at the time stated but in EDT? Yeah, it's always the former, because no one is gonna use a non-DST timezone during DST. Yet, my precise mind always stumbles at this goof.

This is why I always just say "US Eastern". It's always correct, whether DST is in effect or not. An equivalent formulation is just "Eastern Time" or ET, if you really want to use an abbreviation. Or, you could instead refer to a city in your timezone, like for me "New York" or "Washington DC". No ambiguity at all, ironically, by avoiding the needless specification of whether the time involves DST.

Same goes for US Pacific, by the way. "US Pacific" or "PT" is sufficient.

If you want to go real hardcore, you can give all your times in UTC. You never need to worry about DST then, but you put the burden on everybody else to calculate when that is for them. To be honest, though, I think this isn't so bad. When you are working with international employees, you kind of have to know everybody's timezone differences anyway, so you end up knowing the UTC offsets somewhat. Pro tip: Set up a multi-timezone clock and have it handy / always displayed, so you can memorize the offsets.

This is sort of a tangent, but it's related advice: Always log in UTC. Just do it, and don't use the local time ever. Your code will end up running all over the world, and someone troubleshooting it shouldn't need to also know where your Kubernetes pod or whatever was living in order to fully grasp what was going on when.

Anyway: Another trap is that some timezone abbreviations are ambiguous. For example, we have Central European Time (CET), which covers most of continental Europe and parts of Scandinavia. During DST, it's Central European Summer Time (CEST)which, unfortunately, sometimes is written as CST. Which is the abbreviation for Central Standard Time in the US. Or China Standard Time. Or Cuba Standard Time.

List of timezone abbreviations

Some other good ones (and by good I mean bad) relevant to tech:

BST: British Summer Time or Bangladesh Standard Time

IST: India Standard Time or Irish Standard Time or Irish Summer Time (WTF Ireland) or Israel Standard Time

For these, I will just state the timezone by country ("India time", for example) or by the city where some appropriate company office is ("Bangalore time").

Lastly, do remember to state timezones explicitly. Some work cultures are highly focused on the mothership office and it's easy to just omit the timezone in verbal communication, assuming it to be wherever the mothership is. It's nicer and more inclusive to specify the timezone for any event, explicitly, and acknowledge all of your coworkers who live and work around the globe.