Do you work in a command control center with a bank of analog clocks covering the south wall, each with an official looking placard designating which far-flung city it’s assigned to? Neither do I. But I still need the data, and most likely you do too, particularly in a global economy with an increasingly distributed workforce. My software development team is spread out over 4 time zones, and I’m hardly in any kind of minority.
However, when it comes to my team (or my friends and family, for that matter) I don’t care about the time zones. Or the offsets. Or GMT, Zulu, UTC, or foreign Daylight Savings Time rules.
What I really want to do is to be able to hazard a guess as to what they’re up to so that we can effectively communicate. Are they in bed? Having lunch? In the middle of dinner? Likely at their desk (or cafe somewhere), ready to jump into solving something with me? Available next Tuesday for a morning meeting with a customer on the west coast?
The current and future time in their location is the context I need to collaborate with them, not the time in some royal spot in England minus 5, minus 8 and plus 1 hours. And by the way, I live in Brooklyn, not “America/New_York”.
But I’m stuck in 2005
If you do a search for “time zone converter” these days, you still get a result set of mobile-unfriendly, web 1.0-ish solutions covered in drop-downs and date/time pickers from yesteryear.
The top hit even has a “Form assistance” section, where you are instructed “to specify midnight (start of day), select 00/12 am in the Hour-field and 00 in the Minutes field.” Geesh.
In all fairness, there are some clever (and far more modern) ways to visualize time zone differences on the web, namely Every Time Zone from Amy Hoy and Thomas Fuchs, which I reference all the time in the midst of programming tasks. And Google itself does an ok job with very basic queries like “time in London”.
But again, a time zone is just a data point. What I need is time and place context for the people I work with and care about, sometimes all at once, and ideally without having to overlay any time zone knowledge at all.
Solving for time differences by place
Our team took a stab at this problem, and the end result was a command line-ish tool for the web, Slack, and HipChat designed to abstract away the extra step of time zone transposition. It’s called Slash TZ.
Slash TZ is essentially a database of cities around the world combined with a rudimentary natural language parser. With it, you can figure out current times, relative times in the future and the best times to have a call or meeting, all across multiple cities (or multiple teammates, when you have it hooked up to Slack.)
Slash TZ is good at three kinds of time zone conversions:
Right now, somewhere else
Current times in multiple places are the simplest but most widely used query. Just enter something like “chicago, ireland and rome” to get a list of times compared to where you are (we figure that out from your browser).
Relative time differences
Relative time queries can help you with simple planning tasks. For example,“2pm in berlin” or “10:30 for me in sydney and london”.
Optimal meeting times
Figuring out when to coordinate calls or meetings across many cities is arguably the most interesting problem we’ve attempted to solve. With queries like “best time to reach tokyo” and “best time to have a call between Istanbul, LA, and NYC” you’ll get back a list of ideal times, assuming you dislike waking up in the middle of the night.
For the optimal meeting time scenarios, Slash TZ assumes that the best meeting time is somewhere between 9am and 5pm, and attempts to find the overlaps within that range before expanding out, with a bias towards early evenings over early mornings.
Both Slack and HipChat have external interfaces for what they both call slash commands. With slash commands, the apps will recognize preset commands following the “/” character and deliver a response. Slash TZ can be easily hooked up to these interfaces. For Slack, this means that for any query, you can replace a city name with @teammembername and ask things like “best time to reach @davechung”.
So there you have it, time difference context for people and places in the way that you think about it, without the extra offset math steps. If you have any feedback, we’d love to hear it.
Get a monthly digest of helpful articles from around the web for people leading software teams. Absolutely no spam, unsubscribe anytime, and we'll never share your address: