How to Schedule a Meeting Across Three or More Time Zones

A meeting with people in New York, London, and Singapore has no hour where everyone is inside a normal 09:00 to 17:00 working day. That is not a scheduling failure. It is a fact of geography. The task is to find the least bad option and make it stick without a last-minute scramble. Most of the pain comes not from the time math itself but from skipping steps that feel like admin. Here is the sequence that prevents the 4 a.m. dial-in and the double-booked room.

1. Collect every location as a city, not a zone

Ask each person for their city, not their time zone abbreviation. A colleague who says “I’m on Eastern Time” may mean US Eastern, and another may assume Australian Eastern. The phrase “EST” alone is ambiguous year-round and outright wrong when daylight time is in effect. Get the specific city, such as New York, Toronto, or Sydney. That single fact lets you pin the location to an entry in the IANA time zone database, which is what every calendar tool uses under the hood. If you skip this and collect only offsets like UTC-5, you will place the meeting wrong the moment a clock change hits one city but not another.

2. Check the clock change dates for every city involved

Offsets shift on different dates in different countries, and a gap that works in March can break in April. In 2026 the United States moves its clocks forward on 8 March and back on 1 November. The United Kingdom and the European Union change on 29 March and 25 October. That creates two windows where the usual offset is compressed. London is normally 5 hours ahead of New York. From 8 March to 28 March 2026 the gap is only 4 hours, because the US has already sprung forward while the UK waits. The same 4-hour gap returns from 25 October to 31 October, when the UK falls back before the US does. Singapore uses UTC+8 all year and never changes its clocks, so it is 8 hours ahead of London in winter and 7 in summer. If you rely on a remembered offset instead of checking the actual dates, you will send the invite for the wrong hour.

3. Find the overlap window with a tool, not mental arithmetic

Even with three cities, the combinations of offsets and clock change dates become unwieldy fast. Use a meeting planner that accepts city names and shows the local times side by side. The planner accounts for the exact transition dates and surfaces the hours where at least some people are awake. What you will often see with a New York, London, and Singapore trio is that no hour lands inside 09:00 to 17:00 for everyone. The planner makes that visible immediately, which forces the next decision: who takes the early morning or late evening slot. Trying to do this in your head almost always misses a transition day or confuses AM and PM across the International Date Line.

4. Decide who takes the awkward slot and rotate it

Once you accept that someone will join outside standard hours, make the choice explicit. With New York, London, and Singapore in winter, a 07:00 start in New York is noon in London and 20:00 in Singapore. That puts the American colleague early and the Singapore colleague late, while London sits comfortably at lunch. In summer, another option is 16:00 in London, which is 11:00 in New York and 23:00 in Singapore. Here Singapore takes the hardest slot. Neither is ideal, so the fair approach is to rotate. If the series runs weekly, move the pain each time: one week Singapore goes late, the next week New York goes early. Write the rotation rule into the recurring invite or a shared note. Without a stated rotation, the same person tends to absorb the 11 p.m. call indefinitely, and resentment builds long before anyone says anything.

5. Write the time in a way that removes all doubt

A meeting time written as “10:00 AM” without a reference is a trap. The safest format gives the time, the offset, and the city, such as “10:00 New York (UTC-4)” or simply “14:00 UTC.” Writing in UTC shifts the conversion burden to each attendee’s own calendar, which is exactly where it belongs. Calendar tools store events in UTC and convert them for each attendee using the IANA time zone database. If you send an invite that says “Wednesday 09:00 EST” and the recipient’s calendar is set to a different region, the event lands at the wrong hour. Spell out the full reference once in the invitation body. It costs a few seconds and prevents the chain of messages that begins with “Wait, is that my time or yours?”

6. Verify with a world clock before you send

A world clock shows the current local time in each city at a glance. Open it, add the three or four cities, and check that the proposed meeting time looks sensible against the present moment. If London is showing 03:00 right now and you are proposing a call at 14:00 London time, you have probably transposed AM and PM. This step catches the kind of error that a converter does not flag because the math is technically correct but the intent is wrong. Do it thirty seconds before hitting send.

7. Send the invite immediately, with the time in the subject line

A decision that lives only in a chat thread decays within hours. Send the calendar invite while the group is still looking at the thread. Put the meeting time and the reference city or UTC offset directly in the subject line: “Product sync – Wed 15:00 UTC.” That lets people scan their inbox without opening the message. If you delay, someone will forget the rotation agreement and reopen the negotiation from scratch.

A worked example: New York, London, Singapore

A team spread across New York, London, and Singapore needs a weekly check-in. The US clocks spring forward on 8 March 2026. The UK does not move until 29 March. Between those dates, New York is on Eastern Daylight Time (UTC-4) and London remains on UTC+0. Singapore stays on UTC+8. The offsets put London 4 hours ahead of New York and Singapore 8 hours ahead of London. A 09:00 start in New York is 13:00 in London and 21:00 in Singapore. That is a late evening for Singapore. The team agrees to rotate: in week one, Singapore takes the 21:00 slot; in week two, New York takes a 07:00 start, which gives London 11:00 and Singapore 19:00. They write the invitation as “Weekly sync – 13:00 UTC” and note the rotation in the description. On 29 March the UK advances to UTC+1, so the same 13:00 UTC becomes 09:00 in New York, 14:00 in London, and 21:00 in Singapore. The invite holds because UTC does not change. The rotation holds because they wrote it down.

Mistakes that undo the whole effort

Assuming a fixed offset year-round

A person who memorises “London is 5 hours ahead of New York” will schedule wrong for several weeks each spring and autumn. The 2026 gaps of 4 hours from 8–28 March and 25–31 October are not edge cases. They are predictable and recur every year on slightly different dates. Look them up.

Using time zone abbreviations

“EST” is ambiguous. Eastern Time in North America flips between EST (UTC-5) and EDT (UTC-4). In Australia, Eastern Time can mean UTC+10 or UTC+11. Abbreviations are not unique and do not encode daylight saving rules. Use a city name or a UTC offset.

Ignoring the International Date Line

With cities in Asia and the Americas, a meeting on “Tuesday” for one person may be “Wednesday” for another. A time zone converter that shows both the time and the day of the week catches this. Sending an invite for the wrong calendar day is the fastest way to get a no-show.

Leaving the rotation to chance

A team that never states who takes the early slot defaults to the most accommodating person taking it every time. That person eventually burns out or leaves, and the meeting collapses. Name the rotation in the invite.

Sending the invite late

A group that agrees on a time in a chat thread but does not create the event within the hour will re-litigate the decision when someone asks “What did we decide?” three days later. Send the invite while the tab is still open.

A meeting across three time zones will never be perfectly comfortable for everyone. The goal is to make the discomfort predictable, shared, and free of last-minute confusion. That comes down to using cities, checking the actual dates, and writing the time in a form that a calendar can interpret without human guesswork.