π Meeting Planner Across Timezones
Add attendees in different timezones to find overlapping working hours for everyone.
You have a team call to schedule. Your product manager is in New York. Your developer is in Berlin. Your client is in Singapore. You open a spreadsheet, draw out time columns, start converting hours manually β and 20 minutes later you still aren't sure if 3 PM Eastern clashes with someone's midnight. There's a better way, and it takes about 30 seconds.
This guide walks you through exactly how to use a timezone overlap planner to find shared working hours in seconds, understand what "overlap" actually means across half-hour offset zones, and make smarter scheduling decisions when overlap doesn't exist at all.
Why Manual Timezone Math Keeps Breaking
The obvious trap is daylight saving time. New York and London don't always differ by 5 hours β for several weeks each spring and autumn, the gap is 4 or 6 hours because the two regions shift their clocks on different dates. If you remember the offset from last month, it might already be wrong this week.
The subtler trap is half-hour and 45-minute offsets. India operates on UTC+5:30. Nepal is UTC+5:45. Australia's Lord Howe Island uses UTC+10:30 in summer and UTC+11 in winter. When you're trying to find a window that works for New York, London, and Kolkata simultaneously, whole-hour thinking will give you the wrong answer. The correct approach is to check every 30-minute slice of the day.
Step 1 β Add Your Attendees
Start by clicking "Add Attendee" for each person or team in the meeting. You can add up to six locations. For each one, type a short label (like "Singapore Dev Team" or "Client HQ") and choose their timezone from the dropdown. The list covers every major business timezone including the half-hour offsets like Kolkata, Dhaka, and Kathmandu.
The tool ships with New York and London pre-filled so you can see results immediately β change those to match your actual attendees. If you have multiple people in the same timezone, you only need to add that timezone once; what matters is the geographic spread, not the headcount in each location.
Step 2 β Set the Work Day Boundaries
The default assumption is a 9 AM to 5 PM working day. That's a reasonable baseline, but your team might work 8β6, or your client might have a compressed 10β4 schedule. Change the "Work Day Start" and "Work Day End" fields to match the earliest and latest hours that are genuinely acceptable for each attendee.
One useful trick: if you have a team that's notoriously flexible β engineers who answer Slack until 8 PM, for instance β you can bump their personal end hour by setting the global end to something like 20:00. Conversely, if you need to avoid after-school pickups on the US side, set the end to 15:00 and see what that does to your options.
Step 3 β Pick a Reference Date
This step matters more than most people realize. Timezone offsets change on different dates because daylight saving transitions happen at different times around the world. A meeting window that works perfectly on October 28th might not work on November 5th after clocks change. Setting an exact date gives you precise results for that specific day rather than a generic "usually" answer.
The date picker defaults to today, which is fine for immediate scheduling. For planning recurring meetings, pick a date a few weeks out to capture any upcoming DST transitions in your calculation. If you're building a meeting series, it's worth checking a few dates across the span to make sure the overlap window stays consistent.
Step 4 β Read the Results
After you click "Find Overlapping Hours," the tool shows every continuous window where all attendees fall within their working hours simultaneously. Each window is labeled with its UTC start and end time, its total duration, and then the equivalent local time for each attendee β including the day of the week, since a late evening in the US often means the next morning in Asia-Pacific.
The longest window gets a "BEST WINDOW" badge. For any window two hours or longer, that's a genuinely comfortable meeting time; you can hold a full working session without anyone feeling squeezed. A 30-minute or 60-minute window is tight but usable for a focused standup or decision call. If the tool finds multiple windows, the shorter ones often represent "also possible" alternatives for one-on-one calls when the main group doesn't all need to attend.
Step 5 β Use the 24-Hour Heatmap
Below the overlap windows, a heatmap shows the full 24-hour UTC day as colored cells. Dark cells mean nobody is working during that hour. Blue cells mean at least some attendees are available. Bright indigo cells are the overlap hours where everyone is working simultaneously.
The heatmap is particularly useful when there's no full overlap. You can scan it to see which hours come close β maybe five out of six timezones overlap between 8β10 AM UTC, and only one person is outside their window. That's a signal to ask whether that one person can take an early or late exception for the call, rather than assuming the meeting is impossible.
When There's No Overlap at All
Some timezone combinations genuinely don't overlap during normal business hours. A Los Angeles team and a Singapore team, for example, share essentially no working hours on a standard 9β5 schedule: Singapore's 9 AM is LA's 6 PM from the previous evening, and by the time LA opens at 9 AM, Singapore is at 1 AM. The "no overlap" result isn't a bug β it's accurate information.
In that situation, your options are: (1) agree on a designated overlap hour where one team starts early or stays late on a rotating basis, (2) use async video messages for most communication and reserve live calls for critical decisions only, or (3) accept that the meeting will always inconvenience someone and rotate the burden fairly. The heatmap helps you identify the least painful compromise hour β look for the UTC cell where the most attendees are still technically within reach of working hours even if not fully inside them.
A Real-World Example: New York, London, and Mumbai
On a typical winter day, New York is UTC-5, London is UTC+0, and Mumbai is UTC+5:30. Working hours in UTC terms: New York works 14:00β22:00 UTC, London works 09:00β17:00 UTC, and Mumbai works 03:30β11:30 UTC. The overlap of all three ranges is the intersection of those windows β which is empty. There is no single hour where all three are simultaneously between 9 and 5 in their local time.
The planner will show this immediately and the heatmap will confirm it. The practical solution for this team is usually a 7 AM New York call (12:00 UTC), which is noon in London and 5:30 PM in Mumbai β technically outside New York's 9β5 but well within the others. Expand the start time to 7 in the tool and Mumbai's window shifts: 03:30 UTC becomes reachable. This is how teams find their real-world compromise times rather than being stuck with a spreadsheet that says "impossible."
Tips for Recurring Team Meetings
If you're setting a weekly meeting time, run the planner for several upcoming dates to check whether DST changes break your chosen slot. In late October and early November, US and European clocks shift on different weekends, briefly changing the New YorkβLondon gap from 5 hours to 4. That extra hour might open or close your overlap window for a week or two.
For global teams with three or more locations in wildly different regions, consider splitting into regional meetings plus one broader all-hands at a pre-agreed compromise hour. Tools like this planner make it easy to present the tradeoffs clearly to everyone involved β instead of one person dictating a time, you show the data and let the team decide whose inconvenience is most acceptable. That transparency alone tends to reduce friction considerably.
]]>