Skip to main content

Free Meeting Time Planner Across Time Zones

Find a meeting time that works across time zones. Add each participant's city, see a colour-coded 24-hour grid, and copy the best overlapping slot — DST-aware, in your browser.

Written & reviewed by Helperzy Editorial Team · Updated July 2026

DST-awareOverlap finder40+ citiesCopy best slotFree
Participant
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
New York
London
Mumbai / Kolkata
Green score
1
1
1
1
2
2
2
2
2
2
2
2
2
1
1
1
1
1
0
0
0
0
0
0
Working hours (9–18) Shoulder (7–9, 18–20) Night

Best available slot (no perfect overlap)

New York: Mon 7:00 AM

London: Mon 12:00 PM

Mumbai / Kolkata: Mon 4:30 PM

100% Private

Times are converted with your browser's built-in time zone data (DST-aware). Nothing is uploaded.

How to Use Meeting Time Planner

1

Add participants by city

Search the time zone list by city name and add each participant, including your own location. Every person you add becomes a separate row on the 24-hour grid so you can see their local time for the chosen date at a glance.

2

Read the colour-coded grid

Pick the meeting date, then scan the grid where green marks working hours, amber marks the early and late shoulders, and red marks night. The score under each hour column shows how many participants are comfortably within their working day.

3

Copy the best slot

The planner highlights the hour with the most participants in green as the recommended slot. Tap copy to grab a plain-text summary listing that time in everyone's local zone, then paste it into your message or calendar invite.

Plan Meetings That Fit Everyone's Working Day

A meeting time planner takes a single calendar date and a list of people in different cities, then shows you the hours when their working days actually overlap. It is the tool remote teams, recruiters running interviews across continents, and freelancers juggling international clients reach for when "let's find a time that works" turns into painful mental arithmetic. Instead of guessing whether 3pm in London is reasonable for a colleague in Sydney, you see a colour-coded grid: green where a person is inside working hours, amber on the shoulders of the day, and red overnight. The planner then scores every hour by how many people are in the green and points you at the best slot. The mechanism rests on one rule that most timezone tools get wrong: never do fixed-offset arithmetic. This planner converts every hour through the browser's own time zone database using Intl.DateTimeFormat with a timeZone option. For each hour of the anchor person's day it builds the exact UTC instant, then reads back what local hour that instant is for every other participant. Because the conversion asks the tz database directly, daylight saving transitions are handled automatically — a fixed "+5 hours" would silently be wrong for a day or two around every clock change, twice a year, which is the single most common bug in this kind of tool. Working hours default to 09:00–18:00, with amber shoulders at 07:00–09:00 and 18:00–20:00, and the score for a column is simply the number of participants whose local hour lands in the green band. Suppose you add New York, London, and Kolkata and pick a July weekday. Nine in the morning in New York is 14:00 in London and 18:30 in Kolkata. The grid shows New York and London both green at that hour while Kolkata sits in the amber early-evening shoulder, so the column scores two green. Slide earlier and London drops into its pre-work amber; slide later and New York is fine but Kolkata turns red for the night. The planner surfaces the columns with the most green and, in this trio, recommends the late-morning New York band because it is the widest window where two people are comfortably working and the third is still awake — the same overlap the leading planners highlight. Recruiters use it to offer an interview slot that does not force a candidate to take a call at midnight. A support lead planning a handover between a Manila team and a Toronto team reads straight off the grid where the two shifts touch. A founder raising money across US and European investors finds the two-hour band that keeps everyone alert rather than scheduling by luck. A study group with members in three countries picks the evening that is not a 2am call for anyone. In each case the copy button turns the recommended slot into a plain-text summary listing every person's local time, ready to paste into a message. One honest caveat: the planner finds when working days overlap, not whether a specific person is free — it has no access to anyone's calendar, and you should still confirm before sending an invite. The green and amber bands are a sensible default, not a rule; someone who starts at 7am will read the amber shoulder as perfectly fine, so treat the colours as a guide and adjust in your head for early birds and night owls. A second nuance trips people up when a large group spans more than about eight hours of time zones: sometimes no single hour is green for everyone, and the honest answer is that a rotating meeting time, or two separate calls, beats forcing one person to join at 3am every week. The recommended slot in that situation is the least-bad compromise, not a perfect fit, so read the score bar rather than trusting the highlight alone. Everything runs locally in your browser using its built-in time zone data. Nothing about your participants, their cities, or the meeting is uploaded or stored anywhere.

Examples: Meeting Time Planner

Input

New York 09:00 (July weekday) with London and Kolkata added

Result

London 14:00 (green), Kolkata 18:30 (amber) → column scores 2 green

09:00 New York = 13:00 UTC = 14:00 London (BST) = 18:30 IST, converted via Intl with timeZone, not a fixed offset.

Input

Same trio, checked on a January weekday

Result

London 14:00 (still green), because both New York and London shift for DST

A fixed +5h offset would put London at 15:00 in one season; the tz database keeps the 09:00→14:00 mapping correct in both winter and summer.

Frequently Asked Questions – Meeting Time Planner

Every conversion goes through your browser's time zone database using Intl.DateTimeFormat, so daylight saving shifts are applied automatically for the date you pick. It never uses a fixed hour offset, which is why it stays correct even in the weeks around a clock change.