Scheduling Meetings Across Time Zones: Overlaps, Rotations and Invites That Work

Finding the overlap

List each city’s working hours in one reference zone and look for the intersection. A 09:00 call in New York in January is 14:00 in London, 06:00 in Los Angeles, 19:30 in Mumbai and 23:00 in Tokyo.

• New York – London: 5 hours apart, so the overlap is 09:00–12:00 New York time (14:00–17:00 London). In the weeks when only the US has changed its clocks, it grows to four hours.
• San Francisco – London: 8 hours apart. There is no overlap inside a 09:00–17:00 day; an 08:00 San Francisco start meets London at 16:00.
• New York – Tokyo: 14 hours apart in winter. Working days do not overlap at all; the usual compromise is 19:00 in New York, which is 09:00 the next morning in Tokyo.
• London – Sydney: 11 hours in January, 9 in July. An 08:00 London call is 19:00 in Sydney in January and 17:00 in July.

When there is no overlap

• Rotate the inconvenient slot: alternate early and late calls monthly so the same people are not always on at 22:00.
• Split into two sessions — one for the Americas and Europe, one for Europe and Asia-Pacific — with a shared written summary.
• Go asynchronous: recorded updates, written decisions and comment threads replace many status meetings and work in every time zone.
• Protect personal time: agree hours outside which nobody is expected to join, and stick to them.

Writing an invitation nobody misreads

• Name the cities, not abbreviations: “10:00 New York / 15:00 London / 23:00 Singapore”. EST, BST and IST are often used out of season or mean different things — IST is India, Ireland or Israel depending on who writes it.
• Include the date on each side when the meeting crosses midnight for someone: “Tue 19:00 New York = Wed 09:00 Tokyo”.
• Send a calendar invitation rather than a time in an email. Calendar apps store the event in UTC and show it in each attendee’s zone.
• For recurring meetings, say which zone the series follows. A meeting fixed to New York time moves for London attendees twice a year.

Avoiding the daylight-saving trap

Clock changes happen on different dates around the world — mid-March and early November in North America, late March and late October in Europe, and the opposite seasons in the southern hemisphere. For a few weeks each spring and autumn, recurring meetings land an hour earlier or later than usual for part of the team. Put a reminder in the calendar for those weeks, or check the converter before sending the next round of invites.

Logs, deadlines and timestamps

• Deadlines: write “by 17:00 UTC on 3 November” rather than “end of day”. End of day in Sydney is the morning of the same day in London.
• Logs and APIs: store and compare times in UTC or as Unix timestamps, and convert to local time only for display. The Unix timestamp converter shows any timestamp in UTC and your local zone.
• Travel: a flight arriving at 06:00 is local time at the destination. Convert it before booking a pickup or a meeting.

Worked example: a three-region team

A team in New York, London and Bengaluru wants a weekly call in January. India is UTC+5:30 all year, so a 09:00 New York call is 14:00 in London and 19:30 in Bengaluru — already late for the India team. Moving it to 08:00 in New York gives 13:00 in London and 18:30 in Bengaluru, which is within reach of everyone’s working day.

From the second Sunday in March, New York moves its clocks while India does not: the same 08:00 New York call becomes 17:30 in Bengaluru, and from late March 12:00 in London. If the meeting is anchored to New York time, tell the other offices that their local time will move twice a year.

Holidays and working weeks differ too

• Public holidays rarely line up between countries — check the other offices’ calendars before booking a launch or a deadline.
• Several countries in the Middle East work Sunday to Thursday, so Friday meetings miss them entirely.
• Summer and year-end holiday seasons vary: August in much of Europe, Lunar New Year in China and other parts of Asia, the end of December in many Western countries.
• A shared team calendar with each region’s holidays saves a surprising number of “can we move this?” messages.

Habits that make distributed teams work

• Share each person’s working hours in their calendar or profile so colleagues can see availability at a glance.
• Default to written updates for status and decisions, and keep live meetings for discussion that genuinely needs it.
• Record meetings and post notes promptly so people who could not attend at a reasonable hour are not left out.
• Rotate who takes the inconvenient slot, and say thank you when someone joins outside their normal hours.
• Before changing a recurring meeting, check the next few months for daylight-saving changes in every participating region.

Choosing a reference time zone

Teams usually anchor shared schedules to either UTC or the headquarters’ time zone. UTC never changes for daylight saving, so a “15:00 UTC” stand-up is stable all year — but it moves on everyone’s local clock twice a year. Anchoring to headquarters time is more intuitive for the largest group and shifts the inconvenience to everyone else. Either works if it is written down and used consistently in invitations, documents and release schedules.