Time Zone Meeting Planner

What this tool is used for

• Finding an hour that falls in working time for everyone across several regions.
• Checking which participants would be asked to join outside business hours.
• Comparing two candidate slots on how much they inconvenience each zone.
• Planning a recurring call that stays reasonable as daylight saving shifts.
• Seeing at a glance why no slot works, so the meeting can be split instead.

Frequently Asked Questions

How do I find a time that works across zones?

Convert each participant's working window to UTC and intersect them. The overlap shrinks fast: US Pacific and Central European Time share barely two civilised hours, and adding Asia-Pacific usually leaves none.

What is the fairest approach when there is no overlap?

Rotate the inconvenience rather than fixing it on one region permanently. A recurring meeting that is always 6am for the same team is a retention problem, not a scheduling one.

Why do recurring meetings drift?

Because regions change clocks on DIFFERENT dates. The US moves in mid-March and Europe in late March, so for two weeks a transatlantic meeting shifts by an hour — the commonest cause of missed calls each spring.

How should I write the time in an invitation?

With an IANA zone or a UTC offset plus the date, never a bare abbreviation. "3pm CST" is ambiguous across three zones; "15:00 America/Chicago" or "21:00 UTC" is not.

Do calendar invites handle this automatically?

Generally yes — iCalendar stores the zone and each client renders local time. Problems arise with plain-text times typed into the description, which no client converts and everyone reads in their own zone.

Why do offsets change on different dates in different countries?

Because daylight-saving transitions are not synchronised — the US, EU and Australia all switch on different dates, and the southern hemisphere switches in the opposite direction. So a fixed offset between two cities is only correct for part of the year.

Which zones have offsets that are not whole hours?

India at +5:30, Nepal at +5:45, parts of Australia at +9:30, and the Chatham Islands at +12:45. Any scheduling arithmetic assuming whole-hour offsets is wrong for a large population.

Should a recurring meeting be anchored to one participant's zone?

It has to be anchored somewhere, and stating which is what prevents drift. Anchoring to UTC keeps the absolute time fixed and makes the local time move for everyone at each transition.

Common errors and gotchas

• Assuming the offsets stay put. Daylight-saving transitions happen on different dates in different regions.
• Planning by current offset for a meeting weeks away, which can shift by an hour either side.
• Overlooking that a slot crosses midnight for someone, which changes the date as well as the time.
• Treating business hours as identical everywhere, when start times vary by region and role.
• Ignoring local public holidays, which no offset calculation will reveal.