A timezone meeting planner answers a practical scheduling question: when can everyone meet during their own work hours? On Yaya Tools, the live tool lives at /timezone-meeting-planner/. Add up to eight participants with names, IANA city time zones, and work start/end hours for a chosen date. The page finds overlapping work-hour windows, shows each person’s local time (including previous/next day when a slot crosses midnight), and lets you copy a meeting suggestion—all in your browser, with no upload of cities or hours.
People search for a timezone meeting planner, a world meeting time finder, or phrases like “best time to meet across timezones” and “schedule across time zones” when fixed UTC offsets and mental math stop working. Daylight saving time, overnight shifts, and multi-continent teams make a static “plus eight hours” chart unreliable. This tool uses the browser’s IANA timezone data through Intl, so DST rules for America/Los_Angeles, Europe/London, Asia/Shanghai, and other zones update with the date you pick.
What is a timezone meeting planner?
A timezone meeting planner is a scheduling aid that maps several people’s local work windows onto a shared timeline and highlights times when everyone (or as many people as possible) is available. Unlike a single-city clock converter, a world meeting time finder must:
- Accept multiple participants in different regions
- Respect each person’s work start and end hours
- Convert those hours into comparable instants for one calendar date
- Surface local clock times so invitees see “their” afternoon, not only UTC
- Flag when a local time falls on the previous or next calendar day
Yaya Tools’ planner is built for that workflow:
- Up to 8 participants — name, city/IANA zone, work start, work end
- Plan date (UTC day) — pick the day you want to schedule
- Meeting duration — 30, 60, 90, or 120 minutes
- Best overlap window — full overlap when possible; otherwise the strongest partial cover
- 24-hour UTC timeline — colored work blocks and an all-overlap row
- Local times per person — with offset labels and day-crossing cues
- Copy meeting suggestion — paste into chat, email, or a calendar invite draft
It is a planning helper, not a calendar product. It does not send invites, sync Google Calendar or Outlook, or store team rosters. After you find a slot, you still create the event in your own calendar tool.
Cities available in the selector include San Francisco, New York, São Paulo, London, Berlin, Dubai, Mumbai, Shanghai, Tokyo, Sydney, Auckland, and UTC—each wired to the matching IANA identifier (for example America/Los_Angeles, Asia/Tokyo).
How to use this world meeting time finder
The live page is /timezone-meeting-planner/. The flow is short once you know who needs to join.
- Open the timezone meeting planner.
- Set the plan date (the UTC calendar day the timeline represents) and the meeting duration.
- Edit the sample participants or add your own: name, city/timezone, work start, and work end.
- Add more people with Add participant (maximum eight). Remove extras when you have more than two.
- Read the best overlapping window and each participant’s local time range for that slot.
- Scan the 24-hour work hours chart: working segments vs the highlighted full-overlap band.
- Click Copy meeting suggestion to put the UTC range and local lines on the clipboard.
- Optionally click Reset example to restore the sample Shanghai / London / New York trio.
Results refresh when you change the date, duration, names, zones, or hours. The page shows your browser’s resolved local timezone as a badge so you know which device clock the UI is running on.
Privacy note: cities, work hours, and meeting plans are calculated only in the current browser. They are not uploaded to a Yaya Tools server by this page.
Tip: if your source times are Unix timestamps from an API or log, convert them to human dates first with the timestamp tool, then pick the corresponding plan date here. For counting days between two meetings without timezone math, use the date interval calculator.
How overlapping work hours are found
The planner treats one UTC calendar day as forty-eight 30-minute slots (00:00–00:30 … 23:30–24:00 UTC). For each slot it asks: is this participant inside their local work hours at that instant?
Local time for each slot uses Intl.DateTimeFormat with the participant’s IANA zone. That means:
- Offset for London in January can differ from London in July
- Sydney and Auckland shift with Southern Hemisphere DST rules
- Zones without DST (for example Dubai, Shanghai) stay stable year-round
Work hours support overnight bands. If end is earlier than or equal to start, the tool treats the window as crossing midnight—for example 22:00 → 06:00. Equal start and end is treated as “available all day” for that participant.
Meeting duration maps to how many consecutive 30-minute slots you need (60 minutes → 2 slots, 90 → 3, and so on). The page first searches for a window where everyone is working for that full length. If no complete overlap exists, it chooses the best partial window: maximize the minimum attendance across the slot range, then prefer denser coverage when ties appear.
That behavior matches real remote teams: sometimes the honest answer is “no full overlap today,” and the useful next step is the least-bad slot that covers the most people.
Why the timeline is in UTC
UTC is the shared reference so the chart does not pretend one city is “home.” Each row still shows that person’s city and short offset. Reading UTC on the axis while reading local chips in the summary reduces the classic mistake of applying last winter’s offset to a summer date.
Previous day and next day flags
A meeting that sits at 16:00 UTC may be late evening in Tokyo and morning in New York. The local-time display can attach month/day when the start and end of the window fall on different local calendar days, and the UI language around previous/next day exists so an early-morning slot is not mistaken for “same evening.” Always read the local chip before you send invites.
Best time to meet across timezones: practical patterns
Searching for the best time to meet across timezones usually fails for the same few reasons. Use these patterns with the planner instead of guessing.
East Asia + Europe + U.S. East Coast
Shanghai or Tokyo mornings often overlap London afternoons and New York mornings—or they do not, depending on DST. Load three participants with 09:00–18:00 (or your real hours), pick the real meeting date, and let the overlap row speak. Winter and summer dates can move the window by an hour even when wall-clock habits stay the same.
West Coast U.S. + Europe
San Francisco mornings rarely meet London afternoons without someone bending hours. Shorten duration to 30 minutes, or widen European end times, and compare. A timezone meeting planner makes that trade-off visible before you ask someone to stay late.
Overnight coverage teams
Support or ops staff who work 22:00–06:00 can still participate. Set those hours; the overnight rule includes them in the correct UTC slots. Do not convert overnight shifts into “next day 9–5” by hand—that is where errors hide.
Partial attendance is a decision, not a bug
If the summary says the best window covers only some of the group, treat that as input for who can be optional, who should get a recording, or whether to split into two regional syncs. The tool does not invent a full-overlap slot that the hours do not allow.
Schedule across time zones without losing the day
To schedule across time zones cleanly, separate three ideas people often mash together:
- Calendar date — which local day each person experiences
- Instant — the single moment the call starts (UTC range on this page)
- Work policy — whether that instant falls inside agreed hours
The planner helps with (1) and (2) given your (3). It does not know holidays, PTO, or lunch breaks unless you shrink work hours to match. For multi-day project spans (kickoff to ship date) rather than clock times, pair this page with the date interval calculator. For “how old is this timestamp in human time,” use timestamp. Birthday or age questions belong on the age calculator, not here—age math is calendar dates, not meeting slots.
Daylight saving time and IANA rules
DST is why paper offset charts go stale. This page does not store a custom offset table. It asks the browser for IANA zone behavior on the plan date. When your OS timezone database is current, March and November transitions for U.S. and European zones are reflected automatically.
Implications:
- Re-check the same roster after a DST change weekend; the “best” window can move
- Prefer city/IANA picks over typing “UTC+8” by habit—Shanghai and Perth are not interchangeable just because both can be +8 in some seasons
- If two teammates disagree about “what time is it in London,” they may be looking at different dates relative to the UK transition
Because conversion runs locally, results depend on the timezone data shipped with the browser/OS. That is the same source modern calendars use for display.
Copy meeting suggestion and share safely
Copy meeting suggestion builds a short text block: the UTC range plus one line per participant with city and local range (including offset). Paste it into Slack, email, or a calendar description so everyone sees their own time without reverse-engineering yours.
Nothing is posted to Yaya Tools when you copy. Clipboard write happens in the browser. If the clipboard API is blocked, the page reports failure so you can copy manually from the on-screen local times.
Do not paste sensitive internal project names into participant labels if you later screenshot the page for a public channel—names are whatever you type. Prefer first names or role labels when sharing screenshots.
Worked examples
These scenarios match how the product thinks about overlap.
Example 1: Shanghai, London, New York (sample defaults)
Default example participants use roughly 09:00–18:00 (Shanghai) and 09:00–17:00 (London and New York). On many dates a mid-day UTC window can cover all three; on others you may only get a partial cover. Change only the plan date across a DST weekend and watch whether the highlighted band moves.
Example 2: No full overlap
Add San Francisco 09:00–17:00, London 09:00–17:00, and Tokyo 09:00–17:00 with a 120-minute duration. You may see “no complete overlap” and a best partial window. Shorten to 30 minutes or extend one person’s hours to restore a full overlap—those are the levers the chart is meant to reveal.
Example 3: Overnight worker
One participant works 22:00–06:00 in Berlin; others work 09:00–17:00 in New York. Overnight inclusion means late UTC evening / early morning slots can still light up for Berlin. Without overnight support, you would wrongly mark those hours as free time.
Common mistakes when scheduling across time zones
Using a fixed offset year-round. London is not always UTC+0; New York is not always UTC−5. Pick IANA cities and a real date.
Ignoring duration. A 30-minute overlap may exist when a 90-minute one does not. Set duration to the real agenda length.
Reading only your local clock. Confirm each invitee’s chip, especially when previous/next day markers appear.
Assuming equal hours mean equal overlap. Same 09:00–17:00 strings in different zones are different UTC ranges.
Uploading roster data to random converters. Prefer local tools like this page when names and hours are sensitive.
Confusing date span tools with meeting planners. Day counts between milestones are not meeting times—use date interval calculator for spans and this planner for clock windows.
Related time tools on Yaya Tools
Use the timezone meeting planner when the question is “what clock time works for this group on this day?” Use timestamp when you have epoch seconds or milliseconds to decode. Use the date interval calculator for inclusive/exclusive day counts and weekday math. Use the age calculator for completed years, months, days, and next birthday—not for meeting slots.
Together they cover conversion, intervals, personal calendar age, and multi-zone meeting overlap without requiring an account.
Sources and methodology
Named zones and daylight-saving transitions ultimately come from the IANA Time Zone Database, which is updated when political authorities change UTC offsets, boundaries, or daylight-saving rules. Browser formatting follows ECMA-402, the ECMAScript internationalization standard that requires time-zone-aware implementations to use IANA zone identifiers and data.
This page uses the time-zone data available in your current browser and operating system. A device with outdated tzdata may differ from newly announced rules, and governments can change future offsets with limited notice. Confirm critical travel, legal, broadcast, or operational schedules with the relevant organization close to the event.