How this is worked out
Every offset comes from Intl.DateTimeFormat, which reads the IANA time zone database your browser already ships and keeps updated. Nothing here stores an offset in a table.
That is deliberate rather than lazy. Governments change daylight-saving rules at short notice and with no coordination — Mexico abolished most of its DST in 2022, Jordan and Syria moved permanently to standard time in 2022 and 2023, and the EU has been voting to abolish the clock change since 2019 without doing it. Any hardcoded offset table is wrong the week a government changes its mind. Asking the browser means the answer is as current as the device is.
The grid is built by fixing an hour in your city, then asking what instant that is and converting that single instant into every other zone. Doing it the other way round — adding offsets to a wall-clock time — breaks on the two days a year when the offset changes partway through the day.
"Best hour" has to be defined to be useful. Working hours are 09:00–17:00, awake is 07:00–22:00. The tool picks the hour with the most cities inside working hours; where several tie, it prefers the one where fewest people are asleep, and where that ties too, the earliest — so the answer is stable rather than flickering between equally good options.
All of it runs in your browser. No location lookup, no IP geolocation, no request of any kind.
A worked example
- Date
- 24 August 2026
- Your city
- London (BST, UTC+1)
- Proposed hour
- 15:00 London
- New York
- 10:00 — working hours
- Los Angeles
- 07:00 — awake, not working
- Singapore
- 22:00 — asleep
- Cities inside working hours
- 2 of 4
- Best hour for all four
- 14:00 London — still only 2 of 4
When the honest answer is "there is no good time"
Add London, San Francisco and Sydney to a meeting and there is no hour of the day when all three are inside normal working hours. Not a difficult one — none. The spread is nineteen hours, and eight-hour working days cannot cover it.
Most planners will still hand you a "best" time and let you discover the problem when somebody joins at 6am. This one says so directly, and shows how many people are at work, awake, or asleep at every hour, so the trade-off is a decision rather than an accident.
When a group is spread that far, the fair answer is to rotate which region takes the awkward hour. Fixing it permanently on one office — almost always the smallest or the newest one — is a decision that gets made by default and resented for years.
The date is not a detail
The gap between London and New York is five hours for most of the year and four hours for two weeks in March and one week in late October, because the UK and the US change their clocks on different dates. The gap between London and Sydney swings between nine and eleven hours as the two hemispheres move in opposite directions.
This is why the tool asks for a date rather than assuming today. A recurring meeting scheduled in February will shift for some participants and not others in March, and the calendar invite will not warn anybody.
Some places do not change at all. Arizona stays on Mountain Standard Time while Colorado does not, so Phoenix and Denver share a clock for half the year and differ by an hour for the other half. Queensland does not observe daylight saving while New South Wales does, so Brisbane and Sydney separate every October. Both pairs are in the list here for exactly that reason.
Abbreviations lie, offsets do not
Time zone abbreviations are ambiguous and should never be used to schedule anything. "CST" is Central Standard Time in North America (UTC−6), China Standard Time (UTC+8) and Cuba Standard Time (UTC−5). "IST" is Indian, Irish or Israel Standard Time. "BST" is British Summer Time, and also Bangladesh Standard Time.
They are also seasonal. Writing "9am EST" in July is wrong: the US east coast is on EDT then, and half the recipients will silently correct it while the other half will not.
The unambiguous forms are the IANA zone name — America/New_York — or an explicit UTC offset. This page shows the abbreviation because people recognise it, and the offset beside it because that is the part that means something.
The midnight problem
A meeting at 22:00 in Singapore that runs ninety minutes finishes on the following day. Everything about the invitation is correct and somebody will still miss it, because the date in their head is the date the meeting started.
This tool flags every city where the meeting ends after midnight, and every city that is on a different calendar day from you at the chosen hour. Those two cases account for a large share of missed international meetings, and neither is a calculation error — the arithmetic is right and the mental model is wrong.
When you send the invitation, put the date and the zone in the title for anyone more than about six hours away. Calendar software converts correctly; people reading a subject line do not.
Assumptions and sources
- Time zone data
- The IANA Time Zone Database, read through Intl.DateTimeFormat from the copy your browser ships. No offsets are stored in this site.
- Why not a stored table
- DST rules change with little notice — Mexico ended most DST in 2022, Jordan and Syria moved to permanent standard time in 2022 and 2023. A stored table is wrong from the day a government changes its rules until the day the site is rebuilt.
- Definitions
- Working hours are 09:00–17:00 and awake is 07:00–22:00 local. These are the tool's definitions, chosen so "best hour" means something specific; they are not a claim about anyone's actual schedule.
- Verification
- Tested in tools/test/datetime.mjs against known offsets on both sides of daylight-saving transitions in the northern and southern hemispheres, and against zones that do not observe DST at all.