Every distributed team has the same recurring disaster: a meeting booked for 3 p.m. that is actually 3 a.m. for someone. The fix is not a better calendar app. It is a simple method — the overlap window — plus a few habits that stop daylight saving time from ambushing you twice a year.
Start with the overlap window
The overlap window is the set of hours when everyone on the team is normally awake and working. Plot each person's working hours (say, 9 a.m. to 5 p.m. local) on one timeline, and the overlap is where they intersect. A team spread across New York, London, and San Francisco has a window of roughly 9 a.m. to 12 p.m. Eastern — that is 2 p.m. to 5 p.m. in London and 6 a.m. to 9 a.m. in San Francisco. Every recurring meeting should live inside that window, not at its edges.
Add Tokyo and the window shrinks to almost nothing: there is no hour when New York, London, and Tokyo are all in a normal workday. That is a real finding, not a scheduling failure, and it tells you the meeting should not exist as a live meeting at all. Async updates, recorded video, and shared documents are the answer when the overlap window is empty.
Worked example: finding a time for four cities
Suppose you need a one-hour call with people in New York (Eastern), London, Berlin, and Sydney. Start from a base time and convert outward. A 9 a.m. Eastern call is 2 p.m. in London, 3 p.m. in Berlin, and midnight in Sydney — unusable. Shift to 7 p.m. Eastern and you get midnight in London, 1 a.m. in Berlin, and 10 a.m. in Sydney — now Europe suffers. The least-bad option is usually 8 a.m. Eastern: 1 p.m. London, 2 p.m. Berlin, 11 p.m. Sydney. Sydney takes the late slot this time, so rotate the burden next month. Fairness over time matters more than finding a perfect slot, because there usually is not one.
The rotation principle deserves emphasis: if one region always takes the 11 p.m. call, resentment builds quietly. Alternate the awkward slot between regions, or split the meeting into two sessions so nobody is always the one staying up late.
The daylight saving traps
Daylight saving time causes more scheduling errors than any other single factor, because it does not change everywhere on the same day. The United States and Europe shift on different weekends in March and October, which means the gap between New York and London is four hours for a few weeks a year instead of the usual five. A recurring meeting set during those weeks will silently move an hour for one side.
Three more traps to watch:
- Not everywhere observes DST. Arizona, Hawaii, and most of Asia and Africa stay on standard time year-round, so their offset from you changes when you shift and they do not.
- Southern hemisphere DST runs backwards. Sydney is on daylight time during New York's winter, which flips the offset by an hour between seasons.
- Some zones shift by 30 or 45 minutes. India is UTC+5:30 and Nepal is UTC+5:45, so "add five hours" is wrong for both. Always convert with a tool, never from memory.
Habits that prevent the 3 a.m. meeting
- Write times with the city, not just the zone. "3 p.m. ET" is ambiguous during DST transitions; "3 p.m. New York" is not. Better still, give the time in every attendee's zone in the invite.
- Use UTC for anything that repeats. "Every Tuesday at 14:00 UTC" never drifts. Each person's calendar converts it to their local time correctly, including through DST changes.
- Confirm the time in the invite, not the chat. Chat messages saying "see you at 3" are where mistakes live. The calendar invite is the single source of truth.
- Send a 24-hour reminder with local times. One line per attendee — "9 a.m. New York / 2 p.m. London / 11 p.m. Sydney" — catches errors while there is still time to fix them.
- Default to async when the window is empty. A recorded five-minute update plus a shared document beats a midnight meeting every time, and it respects everyone's working hours.
When async beats a meeting entirely
If a meeting exists mainly to share information, it probably does not need to be live. Status updates, decisions with a written record, and feedback on documents all work better asynchronously: people respond in their own working hours, the record is searchable, and nobody loses sleep. Reserve live meetings for brainstorming, conflict resolution, and relationship building — the things that genuinely need people in the same (virtual) room at the same time.
Frequently asked questions
What is the best time for a meeting across US and European time zones?
Late morning Eastern time usually works best: 10 or 11 a.m. Eastern is 3 or 4 p.m. in London and 4 or 5 p.m. in Berlin, which is inside everyone's workday. Avoid early-morning Eastern calls, which land after European working hours, and late-afternoon Eastern calls, which are the middle of the night in Asia.
Why does the time difference between New York and London change?
Because the US and Europe start and end daylight saving time on different weekends. For a few weeks each spring and autumn, the gap is four hours instead of the usual five. Recurring meetings scheduled during those weeks can silently shift by an hour for one side unless the invite is set in UTC.
Should I schedule meetings in UTC?
Yes, for anything recurring or cross-continental. UTC never shifts for daylight saving, so a meeting set for 14:00 UTC stays at 14:00 UTC all year. Each person's calendar converts it to local time correctly, which removes the most common source of scheduling errors.
What do I do when there is no overlapping work hour?
Do not force a live meeting. Switch to asynchronous communication: a recorded update, a shared document, or a message thread that people answer in their own working hours. If a live conversation is truly necessary, rotate the inconvenient slot fairly between regions instead of making one team always take the night shift.