Meeting Time Finder

Reading the grid

Each row is one hour of City A's day, from midnight to 11 PM, with the same instant shown in all three cities beside it. A cell is solid when that hour falls inside that city's working window and faded when it does not. Rows where all three are solid are highlighted and marked with three dots; two dots means two of the three. Where a city has rolled over into the next or previous calendar day, its date appears next to the time — this is the detail that produces meetings scheduled confidently for the wrong day.

The suggested times are the overlapping hours ranked by how close each one sits to the middle of everybody's working day, summed across the three cities. That biases toward mid-morning and mid-afternoon rather than the first or last hour, which is usually what you want: an 8 AM slot that technically falls inside someone's stated hours is a worse recurring meeting than a 2 PM one.

Where the offsets come from

Every conversion here goes through Intl.DateTimeFormat with an IANA zone identifier, which means the browser's own copy of the tz database resolves the offset for the specific date you entered. Daylight saving is therefore correct on both sides of a transition, including the two or three weeks each spring and fall when North America and Europe have switched and the other has not. That gap is real: between the second Sunday in March and the last Sunday in March, New York to London is four hours instead of five, and a recurring 9 AM call lands an hour off for everyone in Europe.

The tool also does not care whether a zone observes DST at all. Phoenix, Honolulu, most of Asia and all of India stay put year-round; Sydney and Auckland move in the opposite direction from the northern hemisphere, so the gap between the US and Australia widens in the northern winter rather than narrowing. None of that needs special handling because none of it is hard-coded.

When there is no overlap

Any three cities spread roughly evenly around the globe will have none. New York, London and Tokyo is the classic case: London and New York share the afternoon, London and Tokyo share the very early morning, and there is no hour that all three keep. The realistic options are a rotation, where the burden of the early or late call moves between offices each time; splitting into two meetings with a written handoff between them; or widening one city's window by an hour, which the tool will immediately show you the effect of.

The two-dot rows are useful for this. They tell you which pairing is cheapest to preserve and which city is the one being asked to give something up, which is a more productive conversation than arguing about a single number.

Writing the invitation

Send a calendar invite rather than a time in an email body — the calendar carries the zone and each attendee's client converts it. When you do have to write a time in prose, name the cities and include the date for each: "Tuesday 9 AM New York / 2 PM London / 6:30 PM Bengaluru". Avoid abbreviations. EST and EDT are different offsets and people use EST year-round for both; IST means India, Ireland and Israel depending on who is typing; CST is claimed by North America and China. City names and UTC offsets are unambiguous, and abbreviations are not.

One thing this tool does not judge is the weekday. It shows the date each city lands on, but it does not know that Friday evening in New York is Saturday morning in Singapore, or that the working week runs Sunday to Thursday in parts of the Middle East. Check the day of the week against the calendar before you send anything.

Questions people ask