gizmobench

Meeting Time Zone Planner

Line up several cities on one day, see whose working hours overlap, and pick a slot everyone can live with. Every offset is looked up in the browser's own time zone database for the date you chose rather than read off a fixed table, so daylight saving is right for that day, including the weeks when one country has changed its clocks and another has not.

Setting the board up from your own time zone.

Working hours
Clock
Offsets are looked up for the date, because they change. A planner that stores London as +1 is wrong for five months of the year, and wrong by a different amount in the week between the UK leaving summer time and America leaving it. This one asks the browser's own time zone database for each city on the day you chose, which is the same data the operating system uses for its clock. Half-hour and quarter-hour zones are shown exactly in the slot text even where the grid rounds them to a cell.

Common questions

Does it handle daylight saving time?
That is the reason it exists. Nothing here stores a city as a fixed offset. For the date you pick, each city's offset is measured by formatting that exact moment into its time zone and reading how far the answer moved, which is the same tzdata your operating system uses for its own clock. It matters most in the gaps: the UK leaves summer time on 25 October 2026 and the United States leaves it on 1 November, so for that one week New York and London are four hours apart rather than the five everyone has memorised. A planner built on a table is silently an hour out for those weeks, every year, in both hemispheres.
What about half-hour and quarter-hour zones like India or Nepal?
They are carried exactly. India is UTC+5:30, Nepal UTC+5:45, the Chatham Islands UTC+12:45, and the written-out slot line shows the real minutes: 00:30, not 00:00. The grid is a strip of one-hour cells, so a city on a part-hour offset shows the hour it falls in and its row is labelled "not a whole hour, cell rounded down" to say so. The shading still uses the exact local time, so 17:30 in Bengaluru is correctly outside a working day that ends at 17:00.
How does it decide which time is best?
It scores all 24 hours and ranks them. Most cities inside working hours wins first, because that is what a time that works means. Fewest cities in the middle of the night comes next, since asking someone to start an hour early is not the same as waking them at 3am. Then it compares the worst-treated single city rather than the total, because a compromise is judged by whoever it hurts most. The earliest hour breaks a remaining tie. When no hour puts everybody inside working hours it says so plainly and offers the best compromise instead of dressing one up as a match.
Can I copy the times into a calendar invite?
Two ways. The chosen slot row gives one line reading "Tue 8 Sep 15:00 EDT · 20:00 BST · Wed 9 Sep 00:30 IST · 05:00 AEST", with a date shown only where the day actually changes. "Copy for the invite" gives a paste-ready block with the full date at the top and one named city per line. Abbreviations come from the browser too, in whichever English locale knows the zone, and where no English abbreviation exists the offset is written instead of one being invented.
My city is not in the list. What do I do?
Search a bigger city in the same zone, or type the IANA name directly, like Europe/Madrid. IANA names one city per zone, usually the largest when the zone was created, which leaves most of the world unable to find itself: there is no Asia/Bengaluru and no America/Boston. So 170 extra city names are bundled and searchable, from Boston, Manchester and Munich to Bengaluru, Shenzhen and Cape Town, each mapped to the zone that governs its clock. Accents are optional in both directions, so "dusseldorf" finds Düsseldorf and "krakow" finds Kraków.
What do the colours on the grid mean?
Green is inside the working hours you set. Amber is the stretch either side that is still askable: the two hours before the day starts and the four hours after it ends, because evenings bend further than early mornings do. Unlit cells are the middle of the night. Working hours that run through midnight, for a night shift, are treated as one continuous window rather than as an error. The strip covers 24 consecutive hours starting at 06:00 in the first city on the board, which starts out as your own.
Will the times still be right in a few weeks?
The DST note scans a year ahead for each city and reports the next date its clocks change, found by sampling the offsets rather than by hard-coding a rule like "last Sunday in October". Rules move: the United States changed its dates in 2007 and the EU keeps voting on abolishing its. So the note tells you which city moves next and when, which is what decides whether a recurring slot survives the season.
Does anything I type leave my browser?
No. The whole tool runs in the page, using the time zone data the browser already ships. There is no account, no upload and no server call. Your board of cities and your working hours are remembered in your own browser's local storage so the tool is where you left it, and clearing your site data removes them.

Offsets come from the browser's own time zone database for the date chosen, so daylight saving is right for that day. Half-hour and quarter-hour zones are exact in the text and rounded to a cell in the grid.