How to Find a Meeting Time Across Time Zones

Work in one clock, not two

The reliable way to do this is to stop converting back and forth. Pick one clock — yours — and express the other person's working day in it.

If they're 7 hours ahead, their 09:00–17:00 is your 02:00–10:00. Now both windows are in the same units and the overlap is just the part they share: 09:00 to 10:00 your time, one hour.

That's the whole method. Enter both offsets and both working days:

Hours you can both make is the headline. Overlap starts is shown in both clocks, and Latest you can start is the figure to actually put in the invite.

The overlap that lives on their next day

Here's the case that mental arithmetic reliably misses.

You work 09:00–17:00 in UTC−8. They work 00:00–08:00 in UTC+1. Shift their day into your clock and it becomes −09:00 to −01:00 — which is to say, it finished before your day started. No overlap.

Except their next morning lands at 15:00–23:00 in your clock, and your day runs to 17:00. That's two real hours, and checking only the same calendar day reports zero.

The planner tests their working day on the previous, same and next day and reports the best of the three. It's not an edge case — it's what happens whenever the difference is large enough to push a whole working day outside your own.

No overlap is a real answer

If you're in US Central and they're in India, two standard nine-to-five days share nothing. The difference is 11.5 hours and no arithmetic will find a window that isn't there.

The planner shows a dash rather than inventing a plausible-looking time. That's the useful output, because it moves the conversation to the actual options:

• Somebody works outside their normal day
• You alternate who takes the inconvenient slot
• The conversation happens in writing instead

A planner that produced a time anyway would be worse than one that says there isn't one.

Why it asks for offsets, not city names

Because a city name doesn't fix an offset.

Most of Europe and North America shift by an hour for part of the year — and they don't shift on the same dates. For a couple of weeks each spring and autumn, the usual difference between London and New York is an hour off what everyone assumes. Meetings get missed in exactly those weeks, every year.

So look up the offset that applies on the date of the meeting, not the one that applies today. Putting that judgement in front of you is more honest than hiding it behind a zone database that goes stale whenever a government changes the rules.

Fractional offsets are real

Roughly a fifth of the world lives somewhere that isn't a whole number of hours from UTC:

Place	Offset	Enter
India	UTC+5:30	5.5
Nepal	UTC+5:45	5.75
Iran	UTC+3:30	3.5
Adelaide / Darwin	UTC+9:30	9.5
Newfoundland	UTC−3:30	−3.5
Chatham Island	UTC+12:45	12.75

The inputs step in quarter hours for that reason. A planner that only takes whole hours quietly excludes all of them.

A three-hour overlap isn't three hours of booking

You can't start a one-hour meeting at any point in a three-hour window — start at the end and there's nothing left.

Latest you can start is the end of the overlap minus your meeting length. If your meeting is longer than the entire window, that field shows a dash, because there's no start time that works and offering one would be worse than offering none.

"CST" means three different time zones

US Central, China Standard and Cuba Standard all abbreviate to CST. There are worse examples, and none of these abbreviations are standardised anywhere.

Two habits fix nearly all of it:

1. Write the UTC offset, not the abbreviation, whenever a time goes in an email.
2. Better: send a calendar invitation. It stores the underlying instant and renders it in each person's local time, so nobody converts anything and a daylight-saving change can't silently move the meeting for one side only.

The arithmetic on this page is for deciding which window to propose. Once it's agreed, hand the actual timekeeping to software that doesn't make mistakes about it.