How to schedule meetings across time zones
Most cross-zone scheduling mistakes come from the same three causes: writing an offset instead of a zone, assuming an overlap exists, and forgetting that the gap changes twice a year.
Anchor to a named zone, not an offset
Write "14:00 Europe/London" or "14:00 London time", never "14:00 UTC+01:00". The offset is only correct until the next transition; the zone name stays correct indefinitely.
When you send an invitation, let the calendar tool carry the zone. Every serious calendar system stores a zone identifier with the event and recalculates local times for each attendee, which is exactly the behaviour you want.
For anything written down outside a calendar — a document, a ticket, a message — include the city or zone alongside the time. A bare "3pm" in a distributed team is an invitation to a missed meeting.
Find the real overlap first
Before picking a time, check whether standard working hours actually intersect. New York and London share roughly three hours of a 09:00–17:00 day. New York and Tokyo share none at all.
When there is no overlap, someone has to work outside normal hours, and that should be an explicit decision rather than an accident. Rotating which side takes the inconvenient slot is the fairest arrangement for a team that meets regularly.
Every difference page on this site shows both clocks and the current gap, and city pages list the overlap with major hubs, so you can check before proposing a slot.
Plan around the transition weeks
The gap between two cities is not constant. Because the United States and the European Union change clocks on different dates, the usual difference between them is off by an hour for a few weeks each spring and autumn.
Recurring meetings are where this bites. A weekly call anchored to one city will move by an hour for everyone in the other city during those windows, without anyone changing the invitation.
Build a habit of re-checking cross-zone commitments in the week before any transition, and confirm the local time on both sides rather than assuming the usual gap holds.
Habits that prevent problems
Use the 24-hour clock in writing. "18:00" cannot be misread; "6:00" without am or pm can, and the mistake is easy to make when converting in your head.
State the date alongside the time when the conversion crosses midnight. A meeting at 23:00 in one city is the following morning in another, and the date is the part people get wrong.
Give asynchronous work a fair chance. If a recurring meeting has no humane slot for a third of the participants, a written update often serves everyone better than a call nobody schedules well.
Try the tools
Frequently asked questions
- What is the best time to schedule a US and Europe call?
- Early afternoon in Europe, which is morning on the US east coast. That window covers the natural overlap. Adding the US west coast pushes the only workable slot to late afternoon in Europe.
- Should I schedule in UTC?
- UTC works well as a written anchor because it never shifts for daylight saving. Participants still need their own local time, so give both: the UTC time and at least one named city.
- How do I handle a team spread across more than eight hours?
- Accept that no single slot works for everyone and rotate the burden, or move the work to writing. Forcing one region to attend permanently outside working hours is the option that quietly costs the most.
- Why did my recurring meeting move by an hour?
- Almost certainly a daylight saving transition on one side only. The meeting stayed fixed in its anchor zone, and your local offset changed relative to it. It will return to normal once both regions have transitioned.