Meeting across time zones: the practical playbook

The problem with calendar invites across zones

A calendar invite sent across time zones is not what most people think it is. It is a small data structure — usually a fragment of iCalendar (RFC 5545) — that encodes a moment in some zone, plus a recurrence rule, plus the recipients. Every recipient's calendar then renders that moment in the recipient's local zone. When this works, it is invisible. When it breaks, it produces some of the most expensive scheduling bugs in distributed work.

The two most common ways it breaks: the sender's calendar has the wrong default zone, and the recurrence rule was anchored to a zone that does not observe DST.

The wrong-default-zone failure happens most often on shared accounts and on travel. A sales engineer in San Francisco sets up a recurring 09:00 client call from a hotel room in Singapore; her laptop has been temporarily set to `Asia/Singapore` so the OS clock matches the wall clock; the calendar inherits the laptop's current zone; the recurring 09:00 invite is now anchored to Singapore time, not Pacific. Two weeks later, back in San Francisco, the team is on a 18:00 call instead of 09:00. The fix is to never schedule recurring meetings while traveling, or to manually override the zone in the invite to the host's home zone.

The recurrence-and-DST failure is more subtle. A 14:00 meeting in `America/New_York`, recurring weekly, is 19:00 in `Europe/London` for most of the year. But for one week each spring (March 8–14, 2026, in the typical U.S. → EU desync window) and one week each fall (October 26 – November 1, 2026), the gap shifts by an hour because the U.S. and the EU don't transition on the same date. If your invite is anchored to `Europe/London` and the host is in New York, the meeting moves an hour earlier in London for that one week. If the invite is anchored to `America/New_York`, it stays at 14:00 ET and shifts to 18:00 in London for that one week. Either way, somebody is on the wrong call.

The cheapest fix is to know which zone the invite is anchored to and to write it explicitly into the meeting description: "Recurring at 09:00 America/New_York; participants in EU should expect a one-hour shift in late March and late October." That single sentence saves more confusion than any tooling.

The "follow the sun" principle

Follow-the-sun is a workflow pattern where a piece of work is handed off across geographies as each region's working day ends, so the work continues 24 hours a day. It is the workflow used by global support desks, security operations centers, and incident-response teams. It is the workflow that does not work for product engineering, design review, or anything requiring shared context.

The good case: a Tier-2 support ticket opened by a customer in Berlin at 16:00 CET. The Berlin agent works on it until 18:00 CET, hands it off to a Toronto agent at 12:00 EST, who works on it until 18:00 EST, and hands it off to a Singapore agent at 06:00 SGT. The customer wakes up the next morning in Berlin and finds a resolution. Total elapsed wall-clock time: about 18 hours. Total elapsed customer wait: one overnight.

The bad case: an engineering feature is "handed off" between Berlin, Toronto, and Singapore. The Berlin engineer finishes their pull request at 18:00 CET. The Toronto engineer picks it up at 09:00 EST and spends 90 minutes re-reading the design doc to figure out what was decided. They make changes, push, and hand off to Singapore at 18:00 EST. The Singapore engineer wakes up, spends 90 minutes re-reading the design doc and the Toronto changes, and pushes their own modifications. Berlin wakes up the next morning to find a feature that has drifted from the original design in two unrelated directions. The total wall-clock time was 24 hours; the total productive engineering time was about 6 hours; the total context-rebuilding time was about 4 hours. A single engineer working 9 hours of focused time would have shipped a better version.

The principle to extract from this: follow-the-sun works for tasks where the state can be fully described in a ticket. It fails for tasks where the state lives in someone's head. Use the follow-the-sun planner to map handoff windows for the former; do not force it onto the latter.

Finding overlap windows

The overlap window is the set of moments when every required participant is inside their own working hours. For two participants in different zones, the math is straightforward. For three or more, it is worth using the find-meeting-time tool, which renders the overlap as a stacked bar across a 24-hour day.

A few specific overlaps come up over and over for distributed teams, so it is worth memorizing them.

US East Coast ↔ UK. The natural overlap is 13:00–17:00 BST = 08:00–12:00 EDT. In winter (US on EST, UK on GMT), it is 13:00–17:00 GMT = 08:00–12:00 EST. This is a four-hour window where everyone is fully present.

US East Coast ↔ India. The natural overlap is 18:00–21:00 IST = 08:30–11:30 EDT. India does not observe DST, so this window does not move. In winter (US on EST), the same India hours map to 07:30–10:30 EST.

UK ↔ India. The natural overlap is 13:30–18:30 IST = 09:00–14:00 BST. In winter (UK on GMT), it is 13:30–18:30 IST = 08:00–13:00 GMT. India does not move; the UK does. The overlap shifts by an hour at each UK transition.

US West Coast ↔ Europe. The overlap is brutal. 09:00–11:00 PDT = 18:00–20:00 CEST. Many West-Coast / European teams give up on synchronous meetings and run async-by-default for everything except a single weekly all-hands.

Asia-Pacific spread (Singapore ↔ Sydney ↔ Tokyo). All three are within four hours of each other and have substantial overlap. SGT (UTC+8), JST (UTC+9), AEST (UTC+10 in winter, UTC+11 in summer). The Sydney-Singapore gap widens by one hour from October to April when Sydney observes DST.

The fully-impossible spread (US West ↔ India ↔ Australia East). There is no moment when all three are inside 09:00–18:00 local. This is a team that has to commit, in writing, to running async. If your team has this spread and is still scheduling weekly meetings, you have a structural problem that no tooling can fix.

For one-off meetings, use the meeting planner and copy the permalink into Slack — the link encodes the time as UTC and renders the local conversion server-side for each visitor, so nobody has to mental-math.

Cultural norms and meeting etiquette by region

Time zone math gives you the shape of the day. Cultural norms decide what shape of the day is actually polite to use.

Lunch hours vary widely. In Spain, the working day is split around a 14:00–16:00 lunch; scheduling a meeting at 14:30 Madrid time will be politely declined. In Germany, lunch is typically 12:00–13:00 and a 13:30 meeting is normal. In Japan, lunch is 12:00–13:00, and meetings during it are unusual. In Mexico, the lunch is closer to 14:00–16:00 in business culture. In India, lunch can be later, 13:00–14:30.

Workday boundaries vary. Northern European teams tend to start at 08:00–09:00 and end firmly at 17:00. American teams tend to start at 09:00 and run later, 18:00 or 19:00. Indian and Filipino teams working on US accounts will routinely take 22:00 calls — but it is never wise to assume that because they will, they should. Find a rotation.

Friday afternoon is dead in much of the world. In Israel and many Muslim-majority countries, Friday is a half-day or full day off. In France, Friday afternoons are unofficial slow time at most companies. In the US, Friday afternoons are heavily used; in Germany, they are mostly empty.

Public holidays are not universal. A scheduled call on July 4 will fail in the U.S.; on May 1, it will fail in most of Europe; on Diwali, it will fail in India; on Lunar New Year, it will fail in China, Vietnam, and Korea. Consult a holiday calendar before scheduling anything that lands in late January, early May, late October, or December.

The general rule: schedule for the participant whose working day is most constrained, not the participant who is most senior. Senior people can move meetings; junior people cannot.

Recurring meetings + DST: the gotcha

The single most expensive cross-zone scheduling bug is the recurring meeting that drifts.

A weekly product review at 14:00 New York time is 19:00 London for most of the year, 19:30 in St. John's (Newfoundland is on a half-hour offset), 23:30 in Mumbai (winter) or 22:30 in Mumbai (summer, because India is fixed at +05:30 and New York moves), 03:00 the next morning in Tokyo (regardless of season — Japan is fixed). For one week each spring and one week each fall, the relationship between New York and London shifts by an hour because the two regions don't transition on the same Sunday.

The mitigation: pin the meeting to the host's zone, write the canonical time in the invite description, and use the meeting drift checker to preview the shifts across the year. If the meeting is genuinely critical, schedule a "transition week" alternate slot in advance.

A second mitigation, often missed: when the host changes — a new manager, a relocation, a re-org — re-anchor the meeting to the new host's zone and re-issue the invite. Leaving the recurrence anchored to the previous host's zone is the most common cause of meetings that "have always been at this time" suddenly moving.

For a fuller treatment of which countries observe DST and when they switch in 2026, see the DST 2026 global overview.

Tools you'll actually use

A small set of tools handles 95% of cross-zone scheduling needs. The remaining 5% is judgment calls about whose convenience to optimize for, and no tool can answer that.

For one-off meetings: find-meeting-time is the lightest path. Pick three to five cities, see the overlap as a stacked 24-hour strip, click the best window, copy the permalink. The link encodes the meeting in UTC and shows each visitor their own local time. This is the link to paste into Slack instead of "15:00 EST", which is wrong half the year anyway.

For converting a specific moment: the time zone converter takes a single timestamp and shows it in every zone you care about. Useful for "what time is the AWS re:Invent keynote in Bangalore?" questions.

For recurring meetings: the meeting planner is the heavier tool — it handles a list of attendees, working-hours preferences per attendee, and recurrence. It is what most distributed teams should standardize on for any meeting that runs more than once.

For background context: the world clock gives you the live state of every major city at a glance, with the ability to pin a watchlist. Useful as a passive reference rather than an active scheduling step.

For trading sessions: the market hours and market overlap pages cover the same problem from a different angle. If your meeting is about trading or finance, the relevant overlap is the trading-session overlap, not the working-hours overlap.

For pasting into chat: the Discord timestamp generator emits an `<t:...>` tag that Discord renders in the viewer's local time. Slack does not support this format natively, but the same UTC-encoded permalink approach works there.

The unifying pattern: encode the moment in UTC at the source, render in local at the destination. Anything else introduces a bug that surfaces every time someone travels or their region transitions to or from DST.

For more on the underlying mechanics, see the complete guide to time zones. For DST specifics in 2026, see the DST 2026 global overview.