Scheduling a meeting across time zones is one of the most annoying recurring problems of remote work. The good news: there's a reliable workflow that takes about two minutes, and once you internalize it, you'll stop making the classic mistakes that lead to "4 AM call" disasters.
The three mistakes everyone makes
- Assuming offsets stay fixed. New York and London are 5 hours apart in winter but 4 hours apart in summer, because both change for daylight saving on different dates. Never compute a difference from memory.
- Using 9–5 in every location. A 9 AM meeting for someone in Singapore is a 9 PM call for someone in San Francisco. There's no "perfect" time — you're always balancing someone's morning against someone else's evening.
- Not checking the actual date. DST transitions mean a difference can change mid-month. The time that worked last week may not work this week.
The step-by-step workflow
1. Pick the working-hour overlap
Define a reasonable window per participant, for example 9:00–17:00. The candidate time is where all those windows overlap. If there's no overlap, someone has to flex — and that decision should be explicit, not accidental.
2. Verify against the current time in each city
Never compute offsets by hand. Look up the live local time in each location and sanity-check that your candidate slot is a reasonable hour everywhere. Our time zone converter shows the current time, UTC offset, and DST status side by side.
3. Check the date boundary
If your candidate time is close to midnight anywhere in the group, confirm the calendar date in every time zone. A meeting at 20:00 in Singapore is 05:00 the same day in Los Angeles — but it can be a different day for someone in Sydney (UTC+11).
4. Record the time in UTC as the single source of truth
Write the invite in UTC, then let everyone's calendar render it in their local time. Calendars (Google, Outlook) do this automatically when you pick attendees. Never type a time like "10 AM PST" into an invite — it's ambiguous and DST-prone. Use a tool that resolves it.
A worked example: Singapore, New York, and London
Say you need to meet with people in Singapore (UTC+8, no DST), New York (UTC-5 winter / UTC-4 summer), and London (UTC+0 winter / UTC+1 summer).
In winter, the overlap of 9–17 windows falls roughly in the late evening in Singapore or early morning in New York — there's no clean overlap. In practice, teams pick either:
- Singapore 20:00–21:00 (their evening), London 12:00–13:00, New York 07:00–08:00, or
- Singapore 08:00 (early), London midnight, New York 19:00 previous day.
Try it live with the meeting planner — it shows you the overlap for any group of cities you pick.
Tips that actually help
- Alternate the bad slot. If someone has to take an awkward time, rotate who gets the inconvenient hour each week instead of always favoring the same time zone.
- Agree on the anchor time zone once. Teams spread across the US + Europe often anchor to UTC or to New York, just to have a stable reference in every invite.
- Mind the DST transition weeks. Twice a year there's a ~3-week window where US and Europe aren't in sync on DST. Check the DST schedule if your meeting spans March–April or October–November.
- Watch out for India's :30 offset. India is UTC+5:30, and a handful of places use :45 offsets (like Nepal, UTC+5:45). "Hourly" meetings can start at odd minutes for those participants.
Frequently asked questions
What's the best time to meet between US and Europe? For US East Coast (UTC-5) and Western Europe (UTC+1), the sweet spot is usually 14:00–16:00 London time = 09:00–11:00 New York time.
What about US West Coast to Asia? San Francisco to Tokyo is roughly a 17-hour gap. A 17:00 Tokyo meeting is 00:00 / midnight in San Francisco — typically there's no good overlap, so one side flexes early or late.
Do I need to worry about DST in August? No — in the northern hemisphere summer, DST is stable across the US and Europe. The danger months are March–April (spring forward) and October–November (fall back).