How to Schedule Meetings Across Time Zones

By WorldTimeWise · Updated October 17, 2026

A meeting scheduled for "10am" means nothing until everyone agrees on *which* 10am. Cross-time-zone scheduling is one of the most error-prone routine tasks in office life, and most of the errors come from the same handful of misunderstandings. This guide covers the mistakes, the practices that prevent them, and the etiquette that keeps teams happy.

The mistakes almost everyone makes

Treating offsets as fixed. The most common error is assuming that the difference between two cities never changes. New York is normally five hours behind London — except when it is four. The gap shifts because the US and the UK start and end daylight saving time on different dates. For about three weeks in March and one week in October/November, the New York–London difference is four hours instead of five. Anyone who hard-codes "EST = UTC−5" or "London is always five hours ahead" will eventually invite someone to a meeting at the wrong time.

Naming a local time without a zone. "Let's meet at 2pm" in an email is ambiguous the moment two time zones are involved. Even "2pm my time" fails when the recipient isn't sure where "my" is. Always attach the zone: "2pm New York time (EDT)". Better still, give the time in UTC as well.

Forgetting that DST is not universal. Most of Asia, Africa, and South America never change their clocks. Parts of Australia do, parts don't. When one side of a meeting observes daylight saving and the other doesn't, the meeting time drifts by an hour twice a year even if nobody touches the calendar entry — unless the invitation was stored with a proper time zone attached (more on that below).

Assuming the other person converts correctly. Even careful colleagues make arithmetic slips, especially with half-hour and 45-minute zones (India at UTC+5:30, Nepal at UTC+5:45). Always state the converted time explicitly in the invitation rather than asking the other person to work it out.

Best practices that actually work

Put UTC in every invitation. The single most reliable habit: alongside the local time, include the UTC equivalent — e.g. "Thursday, October 22, 14:00 EDT / 18:00 UTC". UTC never has daylight saving, never shifts, and is unambiguous everywhere. Anyone, in any zone, with any tool, can convert 18:00 UTC to their own time without knowing what EDT means. WorldTimeWise's time zone converter can produce both sides of any conversion in seconds.

Line up all zones before proposing a time. Don't propose a time and hope it works — visualize first. A meeting planner shows the working hours of every participant's city side by side, so you can see the overlap at a glance instead of doing arithmetic for five people. Look for the window where everyone is within roughly 9am–5pm local, and start from there.

Use the other person's working hours, not yours. A quick check of the world clock tells you whether your proposed 4pm is someone else's 1am. If the overlap is narrow — say, between San Francisco and Singapore — the fair move is to rotate the inconvenience (see etiquette below) rather than always landing it at the same person's evening.

Double-check both directions. Before sending, convert the final time *back* from the invitee's zone to yours. This catches the classic error where the conversion was applied in the wrong direction ("9am their time" entered as "9am my time"). It takes ten seconds and prevents the worst mistakes.

Recurring meetings and DST transitions

Recurring meetings are where time zone scheduling quietly breaks. A weekly standup at "10am New York time" is fine — until a DST transition moves it relative to participants who don't observe DST, or who transition on a different weekend.

The root cause is how the recurrence is stored. If your calendar stores "every Tuesday at 14:00 UTC", the meeting will stay at the same absolute moment all year — which means its *local* time shifts for anyone on daylight saving. If it stores "every Tuesday at 10:00 America/New_York", the local time stays fixed and the UTC moment shifts. Neither is wrong, but you must know which one your tool uses, and participants in other zones need to know which behavior to expect.

Practical rules for recurring cross-zone meetings:

  • Store recurrences with a named zone (America/New_York, Europe/Berlin), never as a bare offset. Named zones carry the DST rules; bare offsets don't.
  • Send a reminder around transition weekends. In the weeks when the US and Europe (or Australia) change clocks on different dates, send a one-line note: "Reminder: clocks change in the US this weekend, so our standup moves from 3pm to 2pm London time." This catches the stragglers whose calendars didn't update.
  • Re-verify twice a year. After each DST transition in any participant's zone, confirm the meeting still lands inside everyone's working hours. A meeting that was comfortable in January can become a 7am or 8pm slot for someone by July.
  • Watch out for the skipped and repeated hours. On "spring forward" weekends, a local time like 2:30am doesn't exist in the transitioning zone; on "fall back" weekends, 1:30am happens twice. Scheduling *in* those windows is asking for trouble — avoid them.

Etiquette for distributed teams

When no time works for everyone, fairness matters more than convenience.

Rotate the pain. If someone has to join at 7am or 9pm, make sure it isn't the same person every week. Alternate between a time that's early for one side and late for the other. Teams that don't rotate breed quiet resentment — the person on the bad slot eventually stops showing up prepared.

Default to the minority's hours occasionally. The person in the lone distant zone (say, one engineer in Tokyo on a US–Europe team) absorbs the worst of every compromise. Deliberately scheduling some meetings at *their* comfortable time, even if it's slightly awkward for the majority, signals that their time counts equally.

Keep a shared "core hours" agreement. Many distributed teams define 3–4 hours of overlap as sacred meeting time and protect the rest as focus time. Publish it, pin it somewhere everyone can see, and don't schedule outside it without asking first.

Record and write up. For anyone who genuinely can't attend, a recording plus written notes is far better than exclusion. But don't use recordings as an excuse to always schedule at the majority's convenience — that's the same unfairness with extra steps.

A quick pre-send checklist

1. Does the invitation name a time zone (or give UTC)?

2. Have you converted it in *both* directions?

3. Is the time inside working hours for every participant? (Check with the world clock if unsure.)

4. For recurring meetings: is the recurrence stored with a named zone, and have you checked the next DST transition?

5. If someone is on an awkward slot, is it their turn — or is it time to rotate?

Get those five right and cross-time-zone scheduling stops being a source of 6am surprises.