What is the best way to plan meetings across time zones?

Use city-based time zones, check the exact date, compare normal working hours and rotate inconvenience when no perfect overlap exists.

Why should recurring meetings use named time zones?

Named time zones include daylight-saving rules, while fixed offsets do not adjust when local clocks change.

How do you make a global meeting fair?

Keep the meeting inside reasonable working hours where possible, rotate early or late slots when no perfect overlap exists, and document the local times in the invite.

Should meeting planners use UTC?

UTC is useful for releases, incidents and public announcements. For human meetings, city-based time zones are usually easier for attendees.

Chrono Time guide

Meeting planner across time zones for fair global teams

A good international meeting time is mathematically correct, easy to read and fair to the people attending. Use named cities, compare the exact date, protect reasonable working hours and document the final local times clearly.

Planning step	Why it matters	Practical example
Use cities	City-based zones include local DST rules.	Use Europe/London and America/New_York instead of GMT and EST.
Check the date	Offsets can change during the year.	London-New York is usually 5 hours, but not every week.
Protect working hours	Correct times can still be unfair.	Rotate early or late calls if APAC and US teams both attend.
Confirm in writing	People scan invites quickly.	Write "15:00 London / 10:00 New York" in the agenda.

Start with named zones

Do not ask a participant for "their timezone" and accept a three-letter abbreviation without context. Ask for the city they work from or the IANA time zone. That gives calendar apps enough information to handle daylight-saving shifts correctly.

Build a fair overlap window

When two cities are involved, choose a time inside both working days. When three or more regions are involved, there may be no perfect answer. In that case, rotate inconvenience instead of repeatedly making the same person join early or late.

A fair meeting planner should separate mathematical overlap from human comfort. A slot can be technically valid and still be poor if it regularly falls before school drop-off, after dinner or outside support coverage.

Planning workflow

Step	Action	Output
1	Collect each attendee city or IANA zone.	Europe/London, America/New_York, Asia/Tokyo.
2	Pick the exact meeting date.	Offsets account for DST on that date.
3	Mark acceptable working hours for each region.	A shortlist of humane overlap slots.
4	Write the final invite with city times.	Example: 15:00 London / 10:00 New York / 00:00 Tokyo.

Real scheduling examples

For London and New York, 14:00 to 17:00 London usually works well. For London, New York and Tokyo together, a single comfortable weekly slot is difficult, so asynchronous updates plus a rotating live meeting may be better than forcing one fixed time.

For launches, incident calls and webinars, use UTC as the neutral reference, then add local examples for the largest audiences.

For a product review with London, New York and Tokyo, a rotating schedule is often better than a permanent compromise. Week one can favor Europe and the US, week two can favor APAC and Europe, and important decisions can be summarized asynchronously for the region that could not attend live.

Suggested overlap patterns

Regions involved	Usually workable pattern	Risk to watch
UK and US East Coast	UK afternoon, New York morning.	DST transition weeks can shift the gap by one hour.
UK, US East and US West	Late UK afternoon, US morning.	Pacific attendees may still be early.
Europe and Japan	Europe morning or early afternoon, Japan evening.	Late Japan calls can become routine if not rotated.
US, Europe and APAC	Rotate live sessions and use async notes.	A single fixed weekly slot usually favors one region too much.

Invite format that reduces confusion

Write the final meeting time in the attendee-friendly format: date, city time and UTC reference if needed. For example: Tuesday, 15:00 London / 10:00 New York / 00:00 Tokyo, with UTC added for engineering releases. This is clearer than relying on a three-letter abbreviation in the title.

FAQ

Should I schedule by UTC or by city?

Use UTC for technical releases and global announcements. Use named city zones for human meetings anchored to offices or teams.

Why do recurring meetings shift?

They shift when one region changes daylight-saving time and another does not change on the same date.

Is a fixed offset enough?

Fixed offsets are risky for recurring events because they do not know local DST rules.

How many time zones can one meeting reasonably cover?

Two or three regions can often work. For four or more distant regions, consider async updates, recordings or rotating live sessions.

What is the biggest scheduling mistake?

The biggest mistake is using a fixed offset or abbreviation without checking the exact date and local DST rules.

Should global meetings always rotate?

Recurring global meetings should rotate when one region would otherwise always attend very early or very late.