How to Schedule Meetings Across Time Zones Without Mistakes

To schedule a meeting across time zones without mistakes, start with each attendee's city, not a fixed offset like "UTC−5." Convert the time for the actual meeting date, because daylight saving time can change the gap between two cities by an hour. Then send a calendar invitation instead of typing the time into a message, and write the time so it can only be read one way.

Most errors come from three habits. People treat a city's UTC offset as if it never changes. They assume every country changes its clocks on the same weekend. And they use abbreviations like "CST" or "IST" that mean different things in different places. This guide covers each problem and works through a three-city example with the arithmetic shown. It ends with a checklist to run before you send the invite.

UTC offsets vs. named time zones

UTC (Coordinated Universal Time) is the world's reference clock. A UTC offset tells you how far a local clock is ahead of or behind UTC at a given moment. In January, New York is UTC−5, Berlin is UTC+1, and India is UTC+5:30.

A named time zone is a region that follows one set of clock rules over time, including when daylight saving time (DST) starts and ends. The standard list is the IANA time zone database, which uses names like America/New_York, Europe/Berlin, and Asia/Kolkata. Phones, operating systems, and calendar apps use it to do their conversions.

The difference matters because one named zone can have two offsets in a year. America/New_York is UTC−5 in winter and UTC−4 in summer. If you write "New York = UTC−5" in a spreadsheet in January and still use it in June, every conversion will be off by an hour.

The rule: record people's cities or named zones. An offset is only correct for a specific date.

Why the time difference between two cities changes during the year

DST moves clocks forward one hour in local spring and back one hour in local autumn. Scheduling across borders gets tricky for three reasons. Not every country uses DST. Countries that do use it switch on different dates. And the Southern Hemisphere's summer happens during the Northern Hemisphere's winter.

The general DST rules by region

These are recent general rules, and the table isn't complete. Other countries that use DST follow their own calendars, and governments can change the rules. Brazil, for example, stopped using DST in 2019. For any country not listed, or one whose policy is in the news, check the current rules before you schedule.

The "gap weeks" between the US and Europe

The US moves its clocks forward two or three weeks before Europe does. In autumn it moves them back one week after Europe. Most of the year, New York is 6 hours behind Berlin. During these gap weeks the difference is only 5 hours. In spring, New York is already on UTC−4 while Berlin is still on UTC+1. In autumn, Berlin returns to UTC+1 a week before New York leaves UTC−4.

So a meeting fixed to New York time that usually lands at 15:00 in Berlin will land at 14:00 during those weeks.

Opposite seasons: London and Sydney

Sydney is UTC+10 in its winter and UTC+11 in its summer. London is UTC+0 in winter and UTC+1 in summer. Because their seasons are opposite, the gap between them takes three different values over a year:

1. Northern winter (e.g., January): Sydney +11, London +0, so Sydney is 11 hours ahead.
2. Late March to early April: London has moved to +1, but Sydney is still on +11, so the gap is 10 hours.
3. Northern summer (e.g., July): Sydney +10, London +1, so the gap is 9 hours.
4. Early to late October: Sydney is back on +11 and London is still on +1, so the gap is 10 hours again.

Places that never change their clocks still see the gap change

India doesn't use DST, but the gap between India and New York still changes because New York's clocks move. In January it's 10.5 hours (5:30 minus −5). In July it's 9.5 hours (5:30 minus −4).

How to find an overlap window for three time zones

Say a team has members in New York, Berlin, and Bengaluru, and they need a 30-minute meeting in January.

1. Look up each offset for the meeting date. In January: New York UTC−5, Berlin UTC+1, Bengaluru UTC+5:30.
2. Ask each person for their acceptable hours, not only their core hours. Assume everyone's core hours are 09:00–17:00 and everyone is willing to stretch to 08:00–19:00.
3. Convert each window to UTC. Use local time − offset = UTC.
   • New York: 08:00 − (−5) = 13:00 UTC, and 19:00 − (−5) = 24:00 UTC (00:00 the next day). The window is 13:00–24:00 UTC.
   • Berlin: 08:00 − 1 = 07:00 UTC, and 19:00 − 1 = 18:00 UTC. The window is 07:00–18:00 UTC.
   • Bengaluru: 08:00 − 5:30 = 02:30 UTC, and 19:00 − 5:30 = 13:30 UTC. The window is 02:30–13:30 UTC.
4. Find the intersection. Take the latest start (13:00, New York) and the earliest end (13:30, Bengaluru). The shared window is 13:00–13:30 UTC, exactly 30 minutes.
5. Check whether core hours alone would work. Converted to UTC, the core hours are New York 14:00–22:00, Berlin 08:00–16:00, and Bengaluru 03:30–11:30. The latest start (14:00) comes after the earliest end (11:30), so there's no overlap. Someone has to stretch.

The table shows the same result hour by hour (January, using UTC + offset = local time):

The same team in July

In July, New York is UTC−4, Berlin is UTC+2, and Bengaluru is still UTC+5:30. Converting the stretched windows again gives New York 12:00–23:00 UTC, Berlin 06:00–17:00 UTC, and Bengaluru 02:30–13:30 UTC. The overlap is now 12:00–13:30 UTC, which is 90 minutes instead of 30.

The window grew because New York and Berlin moved their clocks forward, so their workdays start an hour earlier in UTC. That brings them closer to India. This is why you should always run the conversion for the actual meeting date.

How to write a meeting invitation nobody can misread

Send a calendar event, not just a message. A calendar invite carries its time zone with it, and each attendee's app shows it in their local time. A time typed into an email or chat message doesn't convert for anyone.

Write out the time anyway. Invites get forwarded, copied into documents, and read on devices set to the wrong time zone. A clear format is the weekday, the full date including the year, the UTC time, and then each city's local time:

Tuesday, January 12, 2027 — 13:00–13:30 UTC (08:00 New York / 14:00 Berlin / 18:30 Bengaluru)

The weekday catches date mistakes. If one person reads it as Monday and the invite says Tuesday, someone made an error. The year matters for invites sent around New Year and for notes that get reread months later.

Use city names instead of abbreviations. "CST" can mean US Central Standard Time or China Standard Time. "IST" can mean India, Irish, or Israel Standard Time. People also write "EST" in summer when New York is really on EDT. "New York time" or "ET" (Eastern Time, which covers both) avoids the problem.

Use the 24-hour clock, or write "noon" and "midnight." "12:00 am" confuses a lot of readers. "00:00" or "midnight at the start of Tuesday" doesn't.

Point out when the date changes. In January, Monday 16:00 in San Francisco (UTC−8) is Tuesday 11:00 in Sydney (UTC+11), because the gap is 19 hours. Say this in the invite so nobody shows up a day early or late.

Use a standard format in documents and data. For machine-readable timestamps, the RFC 3339 format (a profile of ISO 8601) puts the offset inside the value, as in 2027-01-12T13:00:00Z. The "Z" means UTC. Software often avoids time zone confusion by storing moments as UTC or as Unix timestamps and converting only when it displays them.

Recurring meetings and the daylight saving trap

Calendar apps usually tie a recurring event to the time zone it was created in. That zone's clock stays fixed, and everyone else's local time moves when DST rules change.

Here's an example. A weekly meeting is created in January for 08:00 New York time, which is 13:00 UTC.

• January: 08:00 New York, 14:00 Berlin, 18:30 Bengaluru.
• After the US switches in March: It's still 08:00 New York, but that's now 12:00 UTC. Berlin is still on UTC+1, so the meeting shows up at 13:00. Bengaluru sees 17:30.
• After Europe switches: 12:00 UTC + 2 = 14:00 in Berlin again. Bengaluru stays at 17:30 until November.

The person in Berlin sees the meeting move an hour earlier for two or three weeks and then move back. The same thing happens for one week in late October or early November, between the EU switch and the US switch. Unless someone warns them, that looks like a mistake.

To prevent this, decide on purpose whose local time stays fixed. Some calendar apps let you set the event's time zone to UTC. Then nobody's region gets special treatment: everyone whose region observes DST sees the meeting move by an hour when their clocks change, and people in places without DST see no change. Either way, add reminders to recheck the series around each switch date that affects your team, plus the Southern Hemisphere dates if anyone lives there.

How to rotate inconvenient meeting times fairly

When the overlap is small or doesn't exist, someone always ends up meeting early or late. Without a plan, that cost usually falls on the same people every time, often the ones farthest from headquarters. If everyone accepts the stretched hours above, the 13:00 UTC slot works every week. A rotation helps when they don't.

A simple fix is to alternate between two slots, each putting the burden on a different person. January offsets, 30-minute meeting. This assumes the team only accepts core hours, where there's no overlap:

Berlin sits in the middle and is within core hours in both slots. That's fine, but say so openly. The middle zone can take on other work, such as writing the notes.

Practices that keep a rotation fair:

• Keep a running count of off-hours meetings for each person, so fairness is something you can check.
• Cap the number of off-hours meetings anyone attends in a week, and let people skip when the cap is reached.
• Record the meeting or write notes, so missing an off-hours slot doesn't mean missing the decision.
• Move status updates to async channels and save live time for discussion that really needs it.
• Check local holidays and weekends. The work week isn't Monday to Friday everywhere, and national holidays differ.

Pre-send checklist

Quick formulas: local time − offset = UTC, and UTC + offset = local time. A negative offset means you add hours when converting to UTC.

1. You know each attendee's city or named time zone, not just an offset you wrote down earlier.
2. You converted using offsets for the actual meeting date, not today's offsets.
3. If attendees are in the US, Europe, Australia, or New Zealand, you checked whether the date falls between the second week of March and early April, or between late September and early November. For any other country, you looked up its current DST rules.
4. The time falls inside every attendee's stated acceptable hours.
5. The invite is a calendar event with a time zone attached.
6. The text gives the weekday, the full date with the year, the UTC time, and each city's local time.
7. There are no ambiguous abbreviations. Times use the 24-hour clock or say "noon" or "midnight."
8. Any change of date for an attendee (crossing midnight or the date line) is pointed out.
9. For recurring meetings, you chose the anchor time zone on purpose and set reminders to recheck around DST changes.
10. The off-hours slot isn't landing on the same person every time.
11. You checked local holidays and work weeks for every attendee.

Frequently Asked Questions

Is GMT the same as UTC for scheduling meetings?

For scheduling, GMT and UTC show the same time. The catch is that London is not on GMT all year. In summer the UK uses British Summer Time (UTC+1), so "London time" and "GMT" are an hour apart for part of the year.

What is the best time for a meeting between the US and Europe?

Most of the year, the US East Coast is 5 or 6 hours behind Western and Central Europe. That makes a New York morning (about 09:00 to 11:00) line up with a European afternoon. The US West Coast is harder: in winter, 09:00 in San Francisco is 18:00 in Berlin, so early Pacific mornings are usually the only workable window.

Why did my meeting suddenly show up an hour off in my calendar?

The usual cause is daylight saving time. The organizer's region changed its clocks and yours didn't, or both changed on different weekends, so the meeting moved in your local time. Other causes are a device set to the wrong time zone or an invite that gave the time as plain text with no zone attached.

Do some time zones really differ by 30 or 45 minutes?

Yes. India uses UTC+5:30, Newfoundland uses UTC−3:30 in winter, Adelaide uses UTC+9:30 in its winter, and Nepal uses UTC+5:45. If you only check whole hours, you can easily be off by 30 minutes for these places.

Should I schedule international meetings in UTC or in my own time zone?

Putting UTC in the invite text gives everyone the same neutral reference. Which zone the calendar event is set to is a separate decision. That zone's local time stays fixed for a recurring meeting, and everyone else's local time can shift when daylight saving time starts or ends.