The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
Part of my work is to attend conference calls with teams in different countries that have different time zone than the country I am currently in.
Question is: When I ask the said teams for a conference call (usually this is done by mail), should I mention the conference call timing in my local time, their local time or GMT time ? Assume that I am dealing with one different time zone.
If you are dealing with just one other time zone, why not mention the time in both your time zone and their time zone?
Let's do the call at 9AM Minneapolis time (4PM for those of you in Paris)
That way there's no confusion for anyone. Whatever you do, just make sure when you mention any time, you are explicit about what time zone you are talking about.
It's important to note here that different locales observe daylight saving and standard time differently (some don't observe daylight saving at all), so take that into account when you do theconversion. The difference between Central time in the US and the time in Western Europe is usually 7 hours, but there are certain times of the year, due to the US being on a different daylight saving schedule, where the difference is only 6 hours.
Also take care that when you do schedule the call, do it at a time that is workable for everyone. If you are in San Francisco and the group you are calling is in Mumbai, don't schedule the call at 2:00 PM your time. That might be convenient for you, but it's 2:30 AM on their side!
You should always include UTC (note, not GMT but UTC, see the already-mentioned comments; GMT is nowaday only used as British winter time).
If you can, also include one or more local times, but do always include UTC.
If the invitation crosses to some place far away (not uncommon in internet times), people might not know what timezone e.g. “PDT” is. Worse, those time zone identifiers are not unique, and there aren’t really any well-understood unique time identifiers (we have Olson timezones for much of the Unix world, but the Windows world differs).
Most people around the world, however, do know the relation of their local time to UTC. If not, time offset calculators are usually easy to find.
Even if the recipient knows which timezone you reside in, they usually would have to calculate UTC first, then their own localtime. Converting a foreign time zone’s timestamp is more error-prone than your own.
There’s something to be said about converting to the well-understood baseline standard on the sender side, so recipents need to only care about their own location in relation to the standard.
This also avoids problems like the international date line, which people living in other parts of the world (if you’re one of them) may not even know about or consider.
If you know a non-negligible subset of your recipients shares one (or a few) common timezones, and if calculation of these offsets is easy enough for you to do it safely, include them as courtesy.
If a recipient is not at their home location, they may have a different timezone which you could not know beforehand. See above for relative ease of calculating from UTC, only now, the recipient’s in a timezone neither you nor them know well, so they’ll likely resort to online tools… or ask a local, who, again, might only know their relation to UTC.
If you’re forced to include a fixed UTC time for each meeting incidence, you won’t have problems with recurring meetings when a part of the recipients switch from/to DST but another part doesn’t.
DST transition times differ between the USA and Europe, for example. (I personally always have “fun” with that with Munzee, who only include what I believe is Texas time, although I know by now that the Eventzee weekend activity ends on Sunday 22:00 in my own timezone except for the few weeks of the year where USA and Europe are out of sync, in which… I actually don’t know.)
So you’ll have either a fixed meeting time in UTC (and everyone will have to schedule their own local-time meetings around it when their own DST transition occurs), or you’ll list the UTC time of all recurrences to fix it to one timezone… or you avoid meetings recurring across DST transitions altogether.
I always list each local time with a label to be sure it's received. If you have too many different time zones to list then you can put GMT and they can convert, but it's nicer to put each local time with a label for each in the email when possible for communication purposes.
