Remote teams rarely fail because someone cannot do arithmetic. They fail because everyone picks a meeting time that feels reasonable locally and nobody checks whether that moment is still inside normal working hours elsewhere. The fix is not memorizing offsets. It is finding the slice of the day when enough people can actually be at their desks without dinner, breakfast, or a midnight alarm.
This guide walks through a repeatable way to find overlapping work hours across time zones, using a three-city example you can swap for your own roster. The goal is a shared window you can defend in writing, not a one-off guess that breaks the next time daylight saving shifts.
Why overlap matters more than time difference
Knowing that London is five hours ahead of New York tells you almost nothing about whether you can schedule a call. What matters is overlap: how many consecutive minutes fall inside each person’s typical workday. A five-hour gap might still leave a two-hour window if both sides start early or finish late. A three-hour gap can leave zero overlap if one team strictly works nine to five and the other does too.
Overlap also changes through the year even when the raw offset between two places stays the same. United States daylight saving time moves Eastern clocks without moving India Standard Time. European summer time does not always start on the same weekend as U.S. spring forward. Teams that picked “10 a.m. New York” in January can discover in March that the same slot is an hour worse for London without anyone changing the invite.
Good scheduling culture treats overlap as a budget. You spend it on meetings that need everyone live. Everything else moves to async updates, recorded demos, or smaller subgroups. When you measure overlap first, you stop treating every timezone gap as an emergency and start treating it as a planning input.
A simple three-step method
Start by writing down each location and the local hours you consider fair game for live meetings. Be honest. If engineers protect mornings for deep work, do not pretend nine a.m. is free just because the calendar is empty. If sales needs late afternoons for customer calls, note that too. You are defining boundaries, not ideals.
Second, pick a reference date. “Today” is fine for recurring standups. For a quarterly review, use the actual meeting date because DST transitions sit on specific weekends. Third, map each person’s window onto a single timeline. A spreadsheet works. So does a dedicated planner that already knows zone rules. What you want is a visual band where all windows intersect.
Once you see the intersection, shrink it on purpose. Leave ten or fifteen minutes at each edge so someone joining from transit or childcare is not instantly late. If the overlap is thinner than forty-five minutes, decide upfront whether the whole group must attend or whether a rotating facilitator model is healthier long term.
Worked example: New York, London, and Bengaluru
Imagine a product trio: a PM in New York (Eastern Time), a designer in London, and an engineering lead in Bengaluru (India Standard Time, UTC+5:30, no DST). Suppose each person accepts meetings between 9:00 a.m. and 6:00 p.m. local.
In late winter, when the U.S. is on standard time, New York at 9:00 a.m. is 2:00 p.m. in London and 7:30 p.m. in Bengaluru. That evening slot in India is already past many people’s preferred end time. Slide New York earlier: 8:00 a.m. Eastern is 1:00 p.m. in London and 6:30 p.m. in Bengaluru. Still tight for Bengaluru, but workable for a focused thirty-minute sync twice a week.
Try the other direction. London at 4:00 p.m. is 11:00 a.m. in New York and 9:30 p.m. in Bengaluru, which is a hard no for sustainable scheduling. The lesson from this triangle is familiar to global teams: the workable band often sits in the late morning Eastern and early afternoon London, with India joining at the end of their day. When the U.S. springs forward, re-run the check. London may still be on GMT for another week or two, and the overlap can widen or narrow by a full hour.
Common mistakes that shrink your window
Labeling invites with ambiguous zone names is the fastest way to lose overlap without noticing. “EST” in July is wrong. “IST” might mean India, Ireland, or Israel depending on who read the invite. Always attach a city or a proper IANA zone in the calendar entry so recurring meetings survive DST.
Another mistake is optimizing for the headquarters clock. If six people sit in one office and two sit abroad, the six will naturally pick mid-afternoon local. That often erases the abroad window entirely. Rotate pain fairly: some meetings can be early for the hub, some late for the hub, so the distant teammates are not always the ones eating dinner at their desks.
Teams also forget lunch and school pickup boundaries. A window that looks fine on paper from 12:00 to 1:00 p.m. local may be socially empty even if calendars show free. Ask once, write the answer down, and treat it like policy.
Finally, do not assume yesterday’s overlap holds next month. Mark DST weekends on the team calendar and re-validate recurring series the week before clocks change. One hour of prevention beats a quarter of standing meetings at the wrong time.
How to use World Meeting Planner for today’s overlap
Manual tables break when you add a fourth city or when half the team travels. The World Meeting Planner on TimezoneMap is built for the intersection problem: add cities, set acceptable local hours, and read the overlap for the date you care about. Use it when onboarding a new site, when someone relocates, or when you are negotiating a standing slot and want a screenshot everyone can agree on.
Practical workflow: list every participant city, set work hours slightly narrower than the official handbook, and scan the next four weeks if a DST change is coming. Export or copy the best window into the calendar template with explicit zone labels. Re-open the planner after travel week; a teammate in “New York” who flew to Denver is now on Mountain Time even if their employment address did not change.
Find today’s shared hours for your roster in the World Meeting Planner.
Overlap is a design constraint, not a morale test. When you document the method, name the edge cases, and re-check around DST, global scheduling stops feeling like guesswork and starts behaving like engineering: measure, adjust, ship.