Scheduling Across Time Zones

Why It's Harder Than It Should Be

Scheduling across time zones goes wrong for boring reasons. Someone writes "3 PM" without saying where, someone else reads a time correctly but converts it in their head at the end of a long day, and twice a year daylight saving shifts one city and not another so a standing meeting quietly moves for half the participants. None of it is difficult. It's just easy to get wrong, and the cost lands on whoever shows up at the wrong hour.

The Rules Worth Following

• Always name the time zone. "3 PM" is not a time if your reader is somewhere else. Write "3:00 PM EST" or, better, "20:00 UTC"
• Use 24-hour time. It removes the single most common error, which is reading an AM as a PM
• Check daylight saving before you commit. Around the March and October transitions, the gap between two cities changes for a few weeks, because they don't switch on the same dates
• Send a converter link with the invite so people can check for themselves rather than trusting your maths — a TimeZonder link does the job
• Rotate who gets the awkward slot if the meeting recurs. Otherwise the same person absorbs it every week

A Workflow That Avoids Most Mistakes

1. Pick two or three candidate times and run each through a converter rather than doing it mentally
2. Send the options with every participant's local time spelled out, so nobody has to convert anything
3. Confirm the agreed time once more in writing, with time zones, before it goes in the calendar
4. Send the invite with an explicit time zone set, and check it landed correctly for at least one person in another region

Worked Examples

A weekly standup across four regions

With people in San Francisco, New York, London and Mumbai, a 9:00 AM slot in New York gives you 6:00 AM in San Francisco, 2:00 PM in London and 7:30 PM in Mumbai. That's early for one person and late for another, which is roughly the best available compromise across that spread — worth naming out loud rather than pretending it suits everyone.

A presentation to a client in another hemisphere

Presenting from Chicago to a client in Tokyo, 8:00 AM in Tokyo is 6:00 PM in Chicago on the previous day. The date change is the part that catches people out: a Tuesday morning meeting in Tokyo is a Monday evening meeting in Chicago, and an invite that gets the time right but the date wrong is still a missed meeting.

The Bottom Line

Scheduling across time zones will never be as simple as scheduling with people down the corridor. Someone is usually inconvenienced, and daylight saving will keep moving things twice a year. What you can control is the ambiguity: say which time zone you mean, verify the conversion with something other than your own arithmetic, and rotate the burden so it doesn't always fall on the same person.

Use it a few times and the "what time works for everyone?" thread mostly stops happening — you paste a link and let people check for themselves.