MeetingHours

Find the hour everyone is awake

Add the cities. The amber column is when all of them are at work. Drag the line to read every clock at once.

Why time-zone maths goes wrong even when you are careful

Converting one time to another is arithmetic, and people are generally good at arithmetic. The errors come from somewhere else. They come from the fact that the offset you are adding is not a constant: it depends on the date, on whether either country happens to be observing daylight saving at that moment, and on whether the two hemispheres are shifting in opposite directions — which for half the year, they are.

A meeting set between London and Sydney in September is a different number of hours apart than the same meeting in November, because Britain falls back while Australia springs forward, and the gap moves by two hours in the space of a few weeks. Neither party did anything wrong. The arithmetic was correct when it was done.

Seeing it instead of calculating it

This tool shows day and night as a band per city, all laid on one timeline. Because each band is offset by that city's real current position, they visibly fail to line up — and the shape of that misalignment is the thing you are actually trying to understand. You are not converting a number. You are looking at where the daylight is.

The amber column marks the hours when every city on the list is inside 9am–6pm locally. When that column is narrow, you can see immediately that there is not much room. When there is no column at all, the tool says so, rather than proposing a time that requires somebody to take a call at four in the morning and pretending that counts as a solution.

The honest failure case matters here. Between San Francisco and Sydney there is no hour of the day when both parties are inside normal working hours — the gap is simply too wide. A planner that always produces an answer is hiding that from you.

The cases that break other converters

Half-hour and quarter-hour offsets are the usual casualty. India runs 5 hours 30 minutes ahead of UTC, Nepal 5 hours 45, and any tool that stores offsets as whole numbers gets both wrong. So are the places that opt out of daylight saving inside a country that observes it: Arizona keeps Mountain Standard Time all year, and Queensland keeps Australian Eastern Standard Time, so both agree with their neighbours for half the year and differ for the other half.

None of that is handled here by special-casing. The browser you are reading this in ships the full IANA time-zone database because it needs it to format dates, and this page reads offsets out of that. The consequence is that the rules are as current as your browser, and there is no offset table on this site that could ever be wrong.

Common conversions

PST → ESTEST → PSTPST → CSTCST → ESTEST → CSTMST → ESTEST → GMTGMT → ESTPST → GMTEST → CETEST → ISTIST → ESTPST → ISTGMT → ISTUTC → IST

All conversions and the plain converter →

Questions

How does it know each city's time without asking a server?
Your browser already carries the full IANA time-zone database — the same dataset that governments' own systems use — because it needs it for every date it formats. This page reads offsets out of that, which means daylight-saving transitions are always current, including the ones announced last month. Nothing is fetched and no zone data is shipped with the page to go stale.
Why is one city marked as the anchor?
The horizontal timeline has to represent somebody's day, and the anchor's midnight-to-midnight is what the width of the chart covers. Every other city's band is offset against it, which is why the bands slide out of alignment — that misalignment is the actual answer you came for. The anchor defaults to your own zone where we can identify it.
What counts as working hours?
Nine in the morning to six in the evening, local to each city. The amber column marks the hours where every city on your list is inside that window simultaneously. If there is no such column, the tool says so plainly rather than suggesting a compromise that has somebody dialling in at 5am.
Does it handle half-hour and 45-minute zones?
Yes. India is UTC+5:30, Nepal is UTC+5:45, parts of Australia are on half-hour offsets and the Chatham Islands are UTC+12:45. These are the cases hand-rolled converters get wrong, because they assume offsets are whole hours. Reading from the browser's own zone data means they come out right without special handling.
What about the hour that daylight saving skips?
When a zone springs forward, a wall-clock time like 2:30am does not exist that day. The tool resolves those to the adjacent real instant rather than silently producing nonsense. If you are scheduling across a DST changeover weekend, check the date as well as the time — that is the single most common way a cross-timezone meeting goes wrong.
Is anything about my meeting sent anywhere?
No. The city list you build is kept in your browser's local storage on your own device, and there is no analytics script on the page. Which cities you are scheduling between can be commercially revealing, and there is no reason for us to know.