Meeting Planner Across Time Zones

Add the places your colleagues are in, say when each of them actually works, and get a ranked answer rather than a grid to squint at. Daylight saving is worked out separately for every person, on the exact day you are planning.

Best times to meet

Hour-by-hour grid

working hours
just outside working hours
night
weekend
Hour-by-hour overlap. Columns are hours in the reference location. Rows are participants. The last column of each row summarises that person's working hours. The final row counts how many people are available in each hour. A ranked list of the best times appears above this table.
------Working hours
London, UK --------
New York, US --------
Tokyo, Japan --------
Available-/--/--/-

Participants

  • London, UK 09:00–17:00
  • New York, US 09:00–17:00
  • Tokyo, Japan 09:00–17:00

Up to 12 participants.

Advertisement

How this meeting planner works

Most overlap tools hand you a coloured matrix and leave you to find the answer in it. This one computes the answer first and shows the matrix underneath as evidence. That ordering is deliberate: the question is always “when should we meet?”, and a twenty-five column grid is a way of not answering it. It also happens to be the only version that works if you cannot see, are using a keyboard, or are holding a phone.

A day is not twenty-four hours

This is the design decision everything else rests on. The columns across the top are not the numbers nought to twenty-three. They are built by stepping one hour of real elapsed time from local midnight in your reference place to the next local midnight, and counting whatever falls in between.

On an ordinary day that produces twenty-four columns and nobody notices. Where the clocks move a full hour, the day they go back produces twenty-five, and two of them read the same hour — they are marked a and b, because they are genuinely different moments an hour apart. The day they go forward produces twenty-three, and one reading is simply absent: there is no column for it because there is no moment for it to describe. A few places move by half an hour instead — Lord Howe Island is the well-known one — and there the count stays at twenty-four, because stepping in whole hours never lands on the half-hour that repeated or vanished.

Building the grid this way means those days are right by construction rather than by special case. The alternative — assume twenty-four hours, then patch the exceptions — is how a planner ends up an hour wrong twice a year, in the direction that looks perfectly normal on screen.

Every cell is worked out at its own instant

A time zone offset is not a property of a place. It is a property of a place at a moment. So no offset here is calculated once and reused down a column or across a row. Each cell asks, for the specific instant that cell represents, what that person's clock reads.

That is more work than caching one offset per person per day, and it is the difference between a planner that is correct on the two most confusing days of the year and one that is not. If your colleague's row seems to shift relative to yours partway across the grid, that is not a rendering glitch — one of you changed clocks and the other did not.

Working hours are minutes, not labels

Each person's working day is stored as two numbers: minutes from their local midnight. That turns “do these people overlap?” into integer arithmetic that can be tested exhaustively, rather than string comparison that has to know a locale.

It also makes overnight shifts work properly. A window from 22:00 to 06:00 wraps midnight, and a shift that starts on Friday night belongs to Friday even when it is running at two in the morning on Saturday. Getting that backwards would mark a night worker unavailable for the second half of every shift they actually work.

The weekend is set per person, and it is not Saturday and Sunday

The working week is not the same everywhere, and assuming otherwise is an accuracy failure rather than a missing preference. Much of the Middle East and North Africa runs Friday and Saturday. Brunei's weekend is Friday and Sunday, with Saturday a working day in between — so a weekend is stored as a list of days here, never as a pair or a range, because a range cannot express it at all.

Each person's weekend is also evaluated in their zone, not yours. A Friday afternoon slot booked from New York is already the weekend in Riyadh, and a Sunday call from London lands on Monday in Auckland. Reading the day of the week from the organiser's clock produces answers that are wrong and entirely plausible.

Worked examples

The twenty-five hour day in New York

Set the reference place to New York and the date to 1 November 2026. The grid grows to twenty-five columns, and two of them read 01:00 — marked a and b. The first is on UTC−04:00, the second on UTC−05:00, and there is a full hour of real time between them.

This is the single best demonstration that the tool is doing arithmetic rather than pattern matching. A colleague in London sees no discontinuity that day — their clocks changed the previous Sunday — so their readings advance smoothly while New York's repeat. Both rows are correct simultaneously, which is only possible because each cell was computed independently.

The twenty-three hour day, and the hour that does not exist

Now try 8 March 2026 in New York. There are twenty-three columns and no 02:00 at all: the column after 01:00 is 03:00. Nothing has been hidden. That wall-clock reading never occurs in New York on that date, so a meeting cannot be scheduled at it, and offering it would be offering a time that does not exist.

A colleague whose weekend is Friday and Saturday

Add a participant in Riyadh, open their settings and set their weekend to Friday and Saturday. Then plan a Friday. Their whole row turns to the weekend band even though the hours 09:00 to 17:00 are unchanged — because a working window says when someone works on a working day, not whether the day is one. The ranked list drops that Friday accordingly, and if you plan a Sunday instead you will see the reverse: Riyadh at their desk while London is not.

What the colours mean, and why they are the third signal

Every cell states its own status three ways: the local time is printed in it, hidden text names the band for screen readers, and the fill and border pattern show it visually. That is deliberate redundancy, not belt and braces.

Colour alone fails for a substantial number of readers, disappears entirely in greyscale printing, and is overridden completely in Windows High Contrast mode — where background images are dropped and colours are replaced by the user's own palette. Any one of those situations would leave a colour-only grid unreadable. The printed hour never goes away.

There is a related limit worth stating plainly rather than glossing. Four different fills cannot all be strongly distinguishable from one another — the contrast between two colours is bounded, and with four bands the arithmetic simply does not allow every pair to clear the threshold that guarantees a visible boundary. Rather than pretend otherwise, each band draws a distinct border pattern and every cell carries its status in words.

Limitations

  • Your device supplies the time zone rules. Every calculation here uses the daylight-saving rules built into your browser and operating system. A device that has not been updated for a long time can carry stale rules for a country that changed them recently. Nothing on this page can detect that.
  • One day at a time. The grid plans a single date. For a recurring meeting, check a date on each side of a clock change — that is when a fixed weekly slot quietly moves for half the participants.
  • Public holidays are not included. Weekends are, because they are a property of a person's week rather than a database that has to be maintained. Holidays are the opposite, and About explains why this site does not carry them.
  • Your participant list never leaves your browser. There is no account, no invitation, and no calendar integration — copy the text summary and paste it wherever your team actually talks.

Sources

Place and country names come verbatim from Unicode CLDR and the IANA Time Zone Database, and this site takes no position on any territorial claim. A territory appears in the list because IANA's country file carries the code — inclusion is a fact about data completeness, not recognition. There are no maps, no flags and no borders anywhere on this site, deliberately and permanently. We quote the time zone database's own header on the point: “It is not intended to take or endorse any position on legal or territorial claims.” The full policy is on the about page.

  • IANA Time Zone Database — the rules your browser carries, and the origin of every zone identifier used here.
  • ARIA Authoring Practices: the grid pattern — the reason the overlap matrix is a plain table rather than an ARIA grid. Grids are for interactive, editable content; static data belongs in a table, where screen readers give row and column navigation for free.
  • WCAG 2.2, Use of Color — why the band is always stated in text as well as shown.
  • Sources lists the city and time zone data this site is built from, with versions and retrieval dates.
Advertisement

Questions

Why are there two 1 AM columns?

Because on that date there are two one-o'clock hours. When clocks go back, the hour repeats: the first runs on the old offset, the second on the new one, and an hour of real time separates them. They are marked a and b so you can tell which one a meeting is actually in — a distinction that matters if anyone joining is in a place that did not change clocks that day.

Why does my colleague's row shift partway across the grid?

Because their clocks changed and yours did not, or the other way round. Countries move their clocks on different dates — the European Union and the United States are two or three weeks apart in spring and exactly one week apart in autumn — so for a few weeks each year the gap between two cities is an hour different from usual. The row is showing you a real event rather than a glitch.

Can I set someone's weekend to Friday and Saturday?

Yes. Open a participant's settings and pick any combination of days, including non-adjacent ones and none at all. The weekend is a list rather than a pair specifically so that Brunei's Friday-and-Sunday arrangement, and three-day weekends, can be expressed properly.

Why don't you show time zone abbreviations like EST or CET?

Because they are ambiguous and not unique. “CST” is used for at least three different offsets around the world, and abbreviations differ between data sources for the same place. The city name plus the actual UTC offset says the same thing without the ambiguity.

Does it handle half-hour and forty-five-minute zones?

Yes. India at UTC+05:30, Nepal at UTC+05:45 and the Chatham Islands at UTC+12:45 all work normally, because nothing here assumes an offset is a whole number of hours. Lord Howe Island, which shifts by thirty minutes rather than an hour, is handled too.

Where is my participant list stored?

In your browser, on your device. It is not sent anywhere and there is no account. Clearing your browser storage clears it, and it will not follow you to another device.