Scheduling Meetings Across Time Zones Without Mistakes

Work Through UTC

The single habit that prevents most errors is to route every conversion through UTC, Coordinated Universal Time, which is the world’s reference clock.

Every time zone is defined as an offset from UTC: New York in winter is UTC−5, London is UTC+0, India is UTC+5:30. To convert a time from one zone to another, first turn it into UTC by subtracting the source offset, then add the destination offset. Converting directly between two zones by adding the difference works too, but it is easier to make a sign error, and UTC gives you a neutral middle step that is hard to get wrong. Think of UTC as the anchor: every local time is just UTC plus or minus that place’s offset, so if you can get a meeting time into UTC, you can express it anywhere.

Always Name the Zone

A time without a zone is ambiguous, and ambiguity is where meetings get missed.

“Let’s meet at 3pm” means nothing to someone in another country. State the zone every time: “3pm New York time,” “15:00 UTC,” or better, give each participant their own local time. When you write it down, prefer a clear format, and consider the 24-hour clock to avoid the am/pm slip that turns a 3pm call into a 3am one. For written invitations, naming the city is friendlier and less error-prone than an offset like UTC+5:30, because most people know where they are but not their current numeric offset, especially during daylight-saving changeovers. The safest single practice is to send the meeting through a calendar system that stores the zone, so each person’s app shows it correctly in their own time.

A Three-City Example

Suppose you want a call at 9am New York time in winter, and you have colleagues in London and India.

New York in winter is UTC−5, so 9am there is 9 + 5 = 14:00 UTC. London in winter is UTC+0, so the meeting is at 14:00, which is 2pm. India is UTC+5:30 all year, so it is 14:00 + 5:30 = 19:30, which is 7:30pm. So one call is 9am in New York, 2pm in London, and 7:30pm in India. The half-hour offset for India is a genuine feature of its time zone, not a rounding error, and Nepal goes further at UTC+5:45. Half-hour and quarter-hour zones like these are easy to forget when you assume every offset is a whole number of hours.

The Daylight Saving Trap

This is the error that recurs like clockwork, twice a year, because the gap between two cities is not constant.

Take the same three cities in the northern summer. New York moves to daylight time, UTC−4, and London moves to UTC+1, but India does not observe daylight saving and stays at UTC+5:30. Now 9am New York is 13:00 UTC, which is 2pm in London and 6:30pm in India. Notice that the India time shifted from 7:30pm to 6:30pm between winter and summer, even though India’s own clocks never changed, purely because New York’s did. That is the trap: a recurring meeting set once can drift by an hour for some participants when any of the involved countries springs forward or falls back, and they do so on different dates. Whenever you schedule across zones, check daylight saving for each city on the specific meeting date, and be especially careful in the changeover weeks when countries are temporarily out of step. Our guide on how to convert time zones covers the offset arithmetic and daylight-saving rules in more depth.

Finding a Fair Overlap

For teams spread across many zones, the goal is not one perfect time but the least-bad overlap, shared fairly.

List each participant’s working hours in their own local time, then find the window where they overlap. Widely separated teams, say the US west coast and East Asia, may have only an hour or two of shared daytime, and sometimes none, which means someone takes the call early or late. When that happens, the fair move is to rotate the inconvenience rather than always favouring one region, so the same people are not perpetually dialling in at 6am. Recording meetings and writing clear summaries also reduces the pressure to get everyone live at once. The arithmetic finds the overlap; the fairness is a choice about who absorbs the awkward hours.

Common Mistakes

• Sending a time with no zone attached, leaving everyone to guess.
• Assuming every offset is a whole number of hours and forgetting half-hour zones like India (UTC+5:30) and Nepal (UTC+5:45).
• Ignoring daylight saving, so a recurring meeting drifts by an hour for some cities twice a year.
• Forgetting that countries change their clocks on different dates, creating a week or two when the usual gap is temporarily wrong.
• Overlooking the date line, where a late-evening meeting in one zone falls on the next calendar day in another.

Frequently Asked Questions

How do I schedule a meeting across time zones?

Convert the proposed time to UTC by subtracting the source zone’s offset, then add each destination zone’s offset to get its local time. Always state the zone or give each person their local time, and check daylight saving for every city on the meeting date. Sending the invite through a calendar app that stores the zone lets each participant see it correctly.

Why is UTC used for time zone conversion?

UTC is the global reference clock, and every time zone is defined as an offset from it. Converting through UTC gives a neutral middle step, so you subtract the source offset to reach UTC and add the destination offset to leave it. This avoids the sign errors that happen when adding the difference between two zones directly, especially with half-hour offsets.

How does daylight saving affect meeting times?

When a country moves its clocks, its offset from UTC changes, so the gap between it and other cities shifts by an hour. A recurring cross-zone meeting can drift for some participants twice a year, particularly since countries change on different dates and some, like India, do not observe daylight saving at all. Always check the rule for each city on the actual date.

What are half-hour time zones?

Some places have offsets that are not a whole number of hours. India is UTC+5:30 and Nepal is UTC+5:45, and there are others. They are genuine, standard offsets, not errors, so a meeting that is on the hour in most cities lands on the half or quarter hour in these. Forgetting them is a common source of thirty-minute scheduling mistakes.

How do I find a good meeting time for a global team?

List each person’s working hours in their own local time and find where they overlap. Widely separated teams may share only a short window, or none, in which case someone must join early or late. The fair approach is to rotate that inconvenience rather than always burden one region, and to record meetings so people who cannot attend live can catch up.

Should I use the 24-hour clock for scheduling?

It helps. The 24-hour clock removes the am/pm ambiguity that can turn a 3pm call into a 3am one, which matters more across zones where a mistake sends people to the wrong half of the day. Pair it with a named zone or city, and the meeting time becomes hard to misread regardless of where the recipient is.

Can a meeting fall on a different day in another time zone?

Yes. A late-evening meeting in one zone can be the early hours of the next day in a zone far to the east, or the previous day to the far west. Always confirm the date as well as the time for widely separated participants, since crossing midnight or the international date line changes which calendar day the meeting sits on for them.

The Bottom Line

Schedule across time zones by converting through UTC, naming the zone every time, and checking daylight saving for each city on the meeting date. Remember half-hour offsets like India’s, and that clocks change on different dates, so the gap between cities is not fixed. For distributed teams, find the overlap and share the awkward hours fairly. When you just need one time converted between two places, the time zone converter does it in a click.