How to Schedule Meetings Across Time Zones

Schedule an instant, not just a clock reading

To schedule a meeting across time zones, collect each participant's location, choose the meeting date, and convert one proposed time for that date. Send a calendar invitation with a named time zone and ask participants to confirm their local display. Recheck recurring meetings around clock changes.

“Let's meet at nine” describes a reading on a clock. It does not identify a shared instant until you know the date and time zone. Even “nine in New York” needs a date if the meeting is in the future, because local offsets can change through the year.

The safest habit is to keep three pieces of information together: the date, the local start time, and the location or named zone that defines it. That makes your proposal easier to check and reduces the need for everyone to perform their own informal arithmetic.

Begin with locations and availability

Ask where each participant will be on the meeting date. A colleague who normally works in Madrid may be traveling in London. Their usual office location is not necessarily the right basis for the invitation.

Then ask for available local hours. A shared business-hour window is a scheduling constraint, not merely a time-zone conversion. Someone may work an early shift, have a school pickup, or be available only on certain days. Knowing that a proposed time is 16:00 locally does not tell you whether it is suitable.

For example, your planning note might contain:

• New York participant: available 09:00–12:00 locally.
• London participant: available 13:00–17:00 locally.
• Madrid participant: available 14:00–17:00 locally.

Convert the windows for the actual date, then look for an overlap that accommodates the meeting's full duration. A 30-minute meeting starting just before the end of someone's availability is not automatically workable.

Use named zones rather than a permanent offset

A fixed offset, such as UTC−04:00, describes the difference from UTC at an instant. A named zone such as America/New_York identifies a set of local-time rules that can include seasonal changes.

The IANA Time Zone Database records local-time histories and is updated when authorities change offsets, boundaries, or daylight saving rules. This is why a location-aware calendar can handle a future date more usefully than a note that says “London is five hours ahead.”

For an ordinary invitation, you do not need to expose a database identifier to everyone. “09:00 New York time” can be clear when paired with the date and a properly configured calendar event. But when working in a calendar's settings, choose the appropriate named location or zone rather than manually fixing the difference from UTC.

Avoid bare abbreviations when they could be ambiguous or seasonally wrong. A city and full date are usually easier for readers to interpret than a string of initials they must look up.

A worked example for three cities

For September 25, 2026, a meeting at 09:00 in New York corresponds to 14:00 in London and 15:00 in Madrid. These are all on the same calendar day. With the example availability windows above, a 30-minute event fits everyone's stated hours.

Write the proposal as a complete sentence:

Proposed meeting: September 25, 2026, 09:00–09:30 New York time; 14:00–14:30 London; 15:00–15:30 Madrid. Please confirm that the invitation shows the expected time in your calendar.

The numbers are an example for that date, not a reusable promise about the difference between the cities. If you move the meeting, reconvert it. If you add a participant, check their local date as well as their time.

Use Kukuepta's world clock to get oriented with current local times, or open the pages for New York, London, and Madrid. These pages show current time; they are not a future-date meeting converter. Use a calendar or date-aware conversion tool for the proposed event.

Why daylight saving creates awkward weeks

Locations do not necessarily change their clocks on the same date. In 2026, the United Kingdom returns to standard time on October 25, while U.S. daylight saving time ends on November 1 in places that observe it.

That produces a useful example. At 09:00 in New York on October 29, 2026, it is 13:00 in London, not 14:00. At 09:00 in New York on November 5, London is back to 14:00. An invitation based on a memorized five-hour difference could be wrong during the intervening week.

The mistake is easy to make because both conversions can look familiar. You may have used 09:00 and 14:00 for months. The date, rather than a new geographic location, changes the result.

For recurring meetings, decide which participant's local time should remain fixed. A weekly event anchored at 09:00 New York time may move in London's local calendar during these transition weeks. An event anchored at 14:00 London time makes the adjustment fall elsewhere. Choose deliberately and tell the group what is being held constant.

Watch for a different calendar day

For more widely separated locations, the local date can differ too. If a proposal is late in the day for one participant, another may already be on tomorrow's date. Always read the entire converted result rather than copying only the hour.

This matters when someone says “Thursday morning,” when a meeting crosses midnight locally, or when a rescheduled event falls on a participant's weekend. A time that looks convenient by its hour can still be on an unavailable day.

Use an unambiguous written date, such as “September 25, 2026,” instead of a numeric form that different countries may read in different orders. If the event spans midnight for anyone, include their end date where needed.

When there is no reasonable overlap, consider whether the work needs a simultaneous meeting at all. A written update, recorded explanation, or shorter call may solve the actual problem. If a call is necessary, alternate inconvenient slots rather than repeatedly assigning the same person the late evening.

Send one invitation and verify it

Create the event in a calendar with its time zone explicitly set. Include the agenda, meeting link, start and end times, and any decision about recurring local times. Use one authoritative event rather than several independent invitations that can drift apart.

Before sending, preview the date in the participants' zones if your calendar supports it. After sending, ask anyone traveling or seeing an unexpected time to check their calendar's current zone setting. If you change the event, update the existing invitation so the group receives one clear correction.

An online alarm can remind you at a local clock time while your browser is open, but it is not a substitute for the shared event. Check its local time against the accepted invitation, especially after traveling. If its sound needs testing, use the online alarm troubleshooting guide.

The final check is small: correct date, correct location, suitable local hours, and one invitation everyone can interpret. Those details matter more than doing the arithmetic from memory.

Sources

• IANA: Time Zone Database — the maintained database of local-time rules.
• GOV.UK: When do the clocks change? — U.K. transition dates and rules.
• NIST: Daylight Saving Time Rules — U.S. transition dates and exceptions.