Why "Let's Meet at 3" Breaks Down Across Borders
A meeting time is only half a fact. "Three o'clock" means nothing until you attach a place to it, yet distributed teams say it every day and then wonder why someone dials in an hour early or a day late. The moment two people sit in different regions, a plain clock time stops being shared information and becomes a small puzzle each person solves differently.
Three things make cross-timezone scheduling quietly error-prone:
- Offsets aren't intuitive. India is UTC+5:30, Nepal is UTC+5:45, and parts of Australia sit on half-hour offsets too. If you do the math in your head assuming whole hours, you will be wrong for a meaningful slice of the planet.
- Daylight Saving Time moves the target. The gap between two cities is not fixed. London and New York are usually five hours apart, but for a couple of weeks each spring and autumn they drift to four or six because the two regions change their clocks on different dates.
- A bare time hides its own ambiguity. "3pm" with no zone is an invitation to guess. Even "3pm ET" trips people up during the weeks when the offset is in flux.
None of this is exotic. It is ordinary scheduling, and the fix is a habit, not a tool you have to buy.
The One Habit That Prevents Most Mistakes
State the zone every single time, and pair it with a city.
Offsets like "UTC+1" are precise but cold; most people can't feel them. City names carry the offset and the DST rules automatically, because everyone knows roughly where London or New York sits. So instead of "let's meet at 15:00," write:
15:00 London / 10:00 New York / 19:30 Mumbai — Thursday 24 July
That single line does several jobs at once. It names the anchor time, translates it for the other participants, and removes the "which 3pm?" question entirely. Nobody has to open a converter to know whether they're free.
A few supporting practices make this bulletproof:
- For written records — contracts, launch times, incident logs — agree in UTC. UTC never shifts for DST, so "the maintenance window opens at 02:00 UTC" reads the same in December and July. Let each reader convert to their own wall clock.
- Prefer city names over raw offsets in human-facing messages. "17:00 Berlin" survives the DST changeover; "17:00 UTC+2" silently becomes wrong when Berlin falls back to UTC+1 in late October.
- Confirm the conversion before you hit send. A quick glance at a world clock showing all your participants' cities side by side catches the off-by-one-hour errors that calendar invites are famous for. It takes ten seconds and saves a missed call.
If you schedule across regions often, keep a reference open that lists the time zones you work with most. Seeing the current offsets in one place — and watching them shift on DST changeover days — turns an abstract rule into something you can just read off.
Finding the Overlap for a Distributed Team
The hardest teams to schedule are the ones stretched across three continents. Consider a common shape: engineers on the US West Coast, product in Western Europe, and a delivery team in India.
Here's the reality of their working days, in UTC (during northern-hemisphere summer):
| Location | Local 09:00–17:00 in UTC |
|---|---|
| US West Coast (PDT, UTC−7) | 16:00 – 24:00 |
| Western Europe (CEST, UTC+2) | 07:00 – 15:00 |
| India (IST, UTC+5:30) | 03:30 – 11:30 |
Look for where the rows touch. Europe and India share a comfortable morning-to-afternoon band (roughly 07:00–11:30 UTC). Europe and the US West Coast share a thin sliver in the European late afternoon (16:00–15:00 — essentially nothing during peak hours, opening up only if the US folks start early or Europe stays late). India and the US West Coast barely meet at all.
That is the uncomfortable truth of a follow-the-sun team: there may be no single hour when all three regions are comfortably at their desks. The best shared window is around 15:00–16:00 UTC, which lands at breakfast for California, late afternoon for Europe, and evening for India. Someone is always making a small sacrifice.
Practical moves when the overlap is this tight:
- Rotate the pain. If a weekly all-hands has to hurt someone, rotate which region takes the awkward slot rather than always taxing the same people.
- Protect one anchor hour. Pick a single overlapping hour and defend it fiercely for the meetings that genuinely need everyone live. Don't spend it on status updates.
- Time-box tightly. When people are joining at 7am or 9pm, a meeting that runs long is a real cost. Publish an agenda and end on time.
When There's No Overlap, Go Asynchronous
If your team spans, say, California and India — a 12.5-hour gap — there is effectively no shared working hour. Forcing a live meeting means someone is on a call at 10pm or 6am, week after week, and that is not sustainable.
The answer is to stop treating live meetings as the default. Push decisions into writing so they don't depend on two people being awake at once:
- Record short video walkthroughs instead of presenting live; the other side watches on their morning.
- Move status and updates into a shared doc or thread that each person reads and replies to during their own day.
- Use a running "handoff" note so the region logging off can pass context to the region logging on.
Async work also benefits from independent timers running in different regions — for reviews, focus blocks, or timeboxed handoffs. A multi-timer lets you track several countdowns at once without mental arithmetic about whose clock is whose.
Reserve the precious overlap hours for the things async genuinely can't do: brainstorming, hard disagreements, and relationship-building.
Daylight Saving Time: The Gotchas That Get You
DST is where confident schedulers get humbled. The rules are not uniform:
- The US and the EU change on different dates. The US "springs forward" in mid-March and "falls back" in early November. The EU shifts on the last Sunday of March and the last Sunday of October. For a couple of weeks twice a year, the New York–London gap is not its usual five hours.
- The southern hemisphere is inverted. When the northern hemisphere springs forward, places like Australia and Chile are falling back. Their winter is your summer, and their clocks move the opposite way.
- Many places don't change at all. Most of Asia, including India and China, and the entire region around the equator, keep a fixed offset year-round. Japan never shifts. Arizona (mostly) doesn't either, while the rest of the US Mountain zone does.
The takeaway isn't to memorize every rule. It's to never assume the gap between two cities is constant, and to re-check the offset around the changeover weeks in March, October, and November. This is exactly why city names beat raw offsets: a tool that knows the rules will show you the right gap on the right date, so you don't have to.
A Practical Pre-Send Checklist
Before you send any cross-timezone invite, run through this:
- Did I state a city or zone, not just a bare clock time?
- Did I include the converted time for each region's participants?
- For anything durable or contractual, did I record it in UTC?
- Is the meeting near a DST changeover date? If so, did I re-verify the offset?
- Did I confirm the conversion against a world clock before sending?
- Is this meeting worth someone's early morning or late evening — or should it be async?
Frequently Asked Questions
Should I schedule in UTC or in local city times?
Both, for different purposes. Use UTC for durable written records — deadlines, maintenance windows, contracts — because it never shifts. Use named city times ("15:00 London") in human-facing invites, because people read their own wall clock, not UTC.
Why does the time difference between two cities change during the year?
Because the two places observe Daylight Saving Time on different dates, or one observes it and the other doesn't. London and New York are five hours apart most of the year but drift to four or six for the weeks when only one side has changed its clocks.
How do I find a fair meeting time for a team on three continents?
Map each person's working hours into UTC and look for where they overlap. Often the only shared window forces someone into an early or late slot, so rotate that burden between regions and reserve the overlap for meetings that truly need everyone live.
What if there's no overlapping working hour at all?
Lean on asynchronous work: recorded walkthroughs, shared docs, and written handoffs that don't require two people awake simultaneously. Save the rare live sessions for brainstorming and hard conversations.
Is "3pm EST" unambiguous?
Not quite. During summer the US East Coast is actually on EDT, not EST, so "3pm EST" in July is technically an hour off. Naming the city — "3pm New York" — avoids the abbreviation trap entirely.
Cross-timezone scheduling stops being a headache the moment you make the zone explicit and check it. Keep a world clock open for your team's cities, bookmark the time zones you work with, and let the tools track the offsets so you can focus on the meeting itself.