World Time Meeting Planner vs plain time-zone converters
Reviewed by the FreeOnline.fyi team · Updated 2026-09-16
What the overlap timeline actually shows
Pick two cities and a date, and the page returns a single headline: something like "Best overlap: 15:00–18:00 (your time) / 09:00–12:00 (their time) — 3 hours". Underneath sits a 24-cell strip, one pill per hour of the day, with the overlapping hours filled in the accent colour and a soft daylight band sitting behind them. Nothing hides behind a submit button — every change to a city selector or the date recomputes instantly.
That headline is not a raw conversion. It counts only the hours where both cities land inside a 08:00–18:00 local band, which is the closest thing to a shared working day when neither side has told you their real hours. If no hour satisfies both, the tool falls back to the closest two-hour window and labels it clearly as outside normal hours. We built it that way because a confidently wrong "great time to meet" is worse than an honest near-miss.
The paired table under the strip carries the detail: one row per hour, City A time on the left, City B time on the right, a +1 / −1 day marker where the dates diverge, and the UTC offset for each side. Overlapping rows are highlighted, so you scan rather than calculate. It all runs client-side from a bundled list of roughly 60 major cities mapped to IANA time-zone IDs, with no lookup API and no account. You can open World Time Meeting Planner and test it with your own pair.
Where a plain converter falls short
A time-zone converter answers "what time is it there?" It hands you an offset and leaves the judgement to you. That is fine for a call you are placing right now, and much less fine for "can we meet Thursday?" — the offset is only half the question.
The other half is whether the resulting hour sits anywhere near a working day for the other person. 09:00 for you and 22:00 for them is a mathematically valid conversion and a terrible meeting. Because the planner starts from a shared window, the answer arrives as something you can accept or reject, not a number you have to interpret on the spot.
There is a date problem too. Offsets are not constants; they move with daylight saving. A converter showing the current offset can be a full hour out for a meeting three weeks away. The planner takes a date input for exactly this reason and applies the DST rules for that date, using the IANA time zone database rules baked into its city list.
Why the date field matters more than you think
Most scheduling mistakes we see happen in the two weeks either side of a daylight-saving switch. The UK and Europe change on the last Sunday in March and October; the US changes on the second Sunday in March and the first Sunday in November. During those staggered weeks, the gap between London and New York is four hours instead of five.
Set the date to the actual meeting date and the planner shows the correct paired hours, including the +1 / −1 day markers that appear when one city has already rolled into tomorrow. Leave the date at today's default and a post-transition meeting will be sitting on the wrong grid.
One honest limitation: the city list is about 60 major hubs, not every municipality on earth. If a colleague is in a smaller town, pick the nearest listed city sharing the same zone — the offsets will match even though the label will not. The planner also will not know that the date is a public holiday for one side. It solves the time arithmetic, not the calendar.
Reading the 24-hour table correctly
Each row pairs one hour of the day in both cities, with the day shift and both UTC offsets spelled out. The chip strip is the quick view; the table is where you confirm the exact minute before anything goes into a calendar invite.
Watch for cities on half-hour or 45-minute offsets. In those rows, one side will read :30 or :45 past the hour, which means the chip boundary and the real local clock do not line up perfectly. The overlap count is built from whole hours inside the 08:00–18:00 band, so treat it as a guide and read the row values before you commit to an odd-minute start.
If your pair has no hour inside the normal band at all — a common result for Auckland and Los Angeles — the tool shows the closest two-hour window with a visible warning rather than pretending a good option exists. That is deliberate. Someone will be outside normal hours; the useful move is to name it, then decide whether to rotate the burden or split the meeting into two shorter calls.
Practical habits for distributed teams
Use the planner to produce a window, then choose an hour nearer the middle of it rather than the edge. A 15:00–18:00 overlap is workable at 15:00, but picking 18:00 pushes the other side late into their evening; the centre of the window usually travels better.
Remember the 08:00–18:00 band is a definition we chose, not a rule anyone agreed to. If your teammate habitually starts at 07:00 or works until 19:00, say so and the usable window is wider than the tool suggests. The planner is a starting point for the conversation, and it is quick enough to re-run with the date of the next occurrence before you send the invite.
For anything that carries weight — a client call, a contract deadline, a hiring panel — verify the final time against an official clock before you commit it. NIST's time services publish authoritative UTC time, and any calendar invite is only as good as the offsets you entered. The planner sits alongside the rest of our free online tools if you want to keep a tab open next to your calendar.