6

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.

Improve this question
10
  • 5
    If you are using Exchange (or something similar) why not suggest a time using the calendar - it automatically adjusts to each user's local time, so no having to specify local vs GMT. Of course, figuring a suitable time for all is another problem. – HorusKol Apr 9 '17 at 11:55
  • 4
    Note: GMT is local time, specifically, GMT is an obsolete alias for WET (Western European (Winter) Time) that is only in use in Great Britain and South Africa. Unless you have participants in Great Britain or South Africa, you should avoid the term. In fact, even then you should avoid it, since the term GMT is used by multiple different organizations to mean multiple different time zones. If you talk about the coordinated global time, GMT hasn't been used for that for 45 years, it was superseded in 1972 by UTC. GMT may at any given time differ from UTC by up to 0.9s; also, local time at … – Jörg W Mittag Apr 9 '17 at 13:26
  • 3
    … Greenwich may confusingly differ from GMT by 1 hour during the summer. It's just not worth the confusion, call it UTC if you want to talk about the coordinated global time, and call it WET (UTC+0) if you are talking about local time in London. – Jörg W Mittag Apr 9 '17 at 13:28
  • 2
    @JörgWMittag: You're right that UTC is preferred and GMT is obsolete, however, GMT will not differ from UTC by up to 0.9s, not unless you're a navigator or astronomer. When used for civil time, GMT is now always equal to UTC. – Dietrich Epp Apr 9 '17 at 14:44
  • 3
    Carrying on from @HorusKol's idea, if you're giving everyone options then you can help solve both problems at the same time by using something like findtime.microsoft.com to make everything appear on everyone's own local-time calendar, and also automate the collection of available and preferred times – Matthew Steeples Apr 9 '17 at 16:14
26

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!

Improve this answer
5
  • 10
    Don't forget the International Date Line. Because if you are calling San Francisco->Mumbai then that the 0230 local time in Mumbai will also be on a different date to San Francisco. – Peter M Apr 9 '17 at 12:37
  • 1
    And don't forget that the time difference between two places does not have to be the same throughout the whole year. E.g. time difference between Zurich, Switzerland and Vancouver, Canada is 9 hours for most of the year, but 8 hours for around two weeks of the year. – RoflcoptrException Apr 9 '17 at 15:43
  • 4
    Also, if you're going to say that something is Standard Time or Daylight Saving Time, make sure you are in the right part of the year. It makes me twitch when someone says that something is going to be at 3 p.m. Eastern Standard Time in the middle of June (where DST is observed). – afrazier Apr 9 '17 at 15:59
  • The fact that we even have daylight saving and standard time makes me twitch, but since they are observed differently in different places it is a good call-out. I'll add a mention to my answer. – Seth R Apr 9 '17 at 18:14
  • @afrazier's comment should be burned into the stone beneath Mt. Rushmore's faces. – Wesley Long Apr 9 '17 at 21:16
7
  1. List all local times.
  2. Label them clearly with the respective city. Time Zone abbreviations are NOT unique: For example CST could be Central Standard Time (Chicago, UTC-6) or China Standard Time (Shanghai, UTC+8) or Cuba Standard Time (UTC-5). Big difference.
  3. Makes sure you have daylight savings time correctly figured in. Different countries switch different dates or not at all
  4. Helpful resource: https://www.timeanddate.com/worldclock/meeting.html
Improve this answer
5

Always include UTC

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.

Rationale:

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.

About including local time

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.

Bonus effects

Recipients on vacation or remoting

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.

DST transitions

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.

Improve this answer
4

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .