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) ^[1] — 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, people turn up an hour early or late.

The two most common ways it breaks: the sender's calendar has the wrong default zone, and the recurrence is anchored to a zone whose DST dates differ from some attendees' zones.

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 call shows up at 18:00 the previous evening 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 two or three weeks each spring (three in 2026, March 8–29; two in 2027, March 14–28) and one week each autumn (October 25 – November 1 in 2026; October 31 – November 7 in 2027), the gap is four hours instead of five, because the U.S. and Europe change clocks on different Sundays. If the invite is anchored to `America/New_York`, it stays at 14:00 in New York and becomes 18:00 in London during those weeks. If it is anchored to `Europe/London`, it stays at 19:00 in London and becomes 15:00 in New York. Either way, one side sees the meeting move.

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 Europe will see it an hour earlier for two or three weeks in March and one week around the start of November." That sentence prevents most of the confusion.

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. Global support desks, security operations centres and incident-response teams use it. It works poorly for product engineering, design review, or anything that depends on shared context.

A good case (illustrative): a support ticket opened by a customer in Berlin at 16:00 CET. The Berlin agent works on it until 18:00 CET and hands it to a Toronto agent (12:00 EST), who works until 18:00 EST and hands it to a Singapore agent at 07:00 SGT, which is midnight in Berlin. The customer wakes up to a resolution about 16 hours after opening the ticket, having waited one night.

A bad case (illustrative): an engineering feature is "handed off" between Berlin, Toronto and Singapore. Each engineer starts their day by reconstructing what the previous one decided, from the design doc and the diff, and each makes changes the others did not discuss. A day later the feature has moved in two directions at once, and much of each person's time went on catching up rather than building.

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. Map the 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 meeting planner, which ranks each hour by how many people it keeps inside working hours and how far outside them it pushes everyone else.

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

US East Coast ↔ UK. With a 09:00–17:00 day on both sides, the overlap is 14:00–17:00 UK time = 09:00–12:00 New York time, three hours; four if New York starts at 08:00. The local times stay the same in summer and winter, except in the desync weeks, when the overlap grows by an hour.

US East Coast ↔ India. There is no overlap between two 09:00–18:00 days: 09:00 in New York is already 18:30 (summer) or 19:30 (winter) in India. The usual compromise is an Indian evening slot such as 18:00–21:00 IST, which is 08:30–11:30 EDT in summer and 07:30–10:30 EST in winter. India does not change its clocks, so the U.S. side moves.

UK ↔ India. With 09:00–18:00 days on both sides, the overlap is 13:30–18:00 IST = 09:00–13:30 BST in UK summer, and 14:30–18:00 IST = 09:00–12:30 GMT in UK winter. India does not move; the UK does, so the overlap changes 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 three hours of each other and have substantial overlap: Singapore UTC+8, Tokyo UTC+9, Sydney UTC+10 (UTC+11 from October to April, when Sydney observes DST, which widens the Sydney–Singapore gap to three hours).

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 paste the share link into chat. The link stores the chosen time in UTC, so it shows the right local time on any device.

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. In Spain, lunch is often taken around 14:00–15:30, later than in most of Europe, so an early-afternoon Madrid slot may clash. In Germany and Japan, 12:00–13:00 is typical. In Mexico, business lunches often run from about 14:00. These are tendencies, not rules; ask the people involved.

Workday boundaries vary. Teams working for clients in other regions often take late or early calls. That they will does not mean they should every week; rotate the inconvenient slot.

The weekend is not the same everywhere. In Israel and in several Muslim-majority countries, including Saudi Arabia, Egypt and Qatar, the weekend is Friday and Saturday, so Friday is not a working day. The UAE moved to a Saturday–Sunday weekend in 2022, with Friday a half day for government offices.

Public holidays are not universal. A call on July 4 will miss most of the U.S.; on May 1, much of Europe ^[3]; on Diwali, India; around Lunar New Year, China, Vietnam and South Korea. Check a holiday calendar for anything that lands in late January to mid-February, early May, October–November or late 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 in London for most of the year, 15:30 in St. John's (Newfoundland is 90 minutes ahead of New York all year), 23:30 in Mumbai in summer and 00:30 the next day in winter (India stays on +05:30 while New York moves), and 03:00 the next day in Tokyo in summer but 04:00 in winter. For two or three weeks in March and one week around the start of November, New York and London are four hours apart instead of five.

The mitigation: pin the meeting to the host's zone, write the canonical time in the invite description, and check one occurrence in each DST transition week with the time zone converter, which takes a date as well as a time. 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 covers most cross-zone scheduling. The rest is judgment about whose convenience to favour, which no tool can decide.

For one-off meetings: the meeting planner ranks the hours for everyone's cities and working hours and exports the chosen slot as a calendar (.ics) file. To share a time in chat, use its share link, which stores the chosen hour in UTC, instead of "15:00 EST", which is the wrong label for New York for about eight months of the year.

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 handles a list of participants and recurring weekly windows at today's offsets. To see where the slot lands in a DST transition week, enter that week's date in the time zone converter.

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 stock market hours guide covers 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.

Glossary

Follow-the-sun

A workflow pattern in which a task is handed off across geographies as each region's working day ends, so the work proceeds 24 hours a day. It is the standard model for global support desks, network operations centres, and incident response. It works for tasks whose state can be fully described in a ticket, and tends to fail for product, design, or engineering work whose context lives in a person's head.

Overlap window

The set of moments during which every required participant in a multi-zone meeting is inside their own working hours. For two participants the overlap is a single contiguous interval; for three or more it can be empty. The overlap is the only window in which a synchronous meeting can be scheduled without forcing somebody to take the call outside business hours.

Time zone offset

The signed difference, in hours and minutes, between a local civil time and UTC at a given moment. The offset is not a permanent property of a place — it changes whenever the region transitions into or out of daylight-saving time, and whenever a government changes its time-zone rules. The offset is what gets rendered to the user; the IANA identifier is what should be stored.

DST gotcha

The class of recurring-meeting bugs caused by daylight-saving transitions happening on different dates in different regions. The most common case is the U.S. and Europe not switching on the same Sunday, which leaves New York and London four hours apart instead of five for two or three weeks in March and one week around the start of November. The mitigation is to anchor recurring invites to a single canonical zone and write the canonical time into the invite description.

iCalendar TZID

The `TZID` parameter on a `DTSTART` field in an iCalendar (RFC 5545) event, which records the IANA time zone of the event's start time. Calendars that store and respect `TZID` produce correct recurrences across daylight-saving transitions; calendars that store only an offset or a local-time string drift by one hour at every transition.

Async-by-default

A working norm where teams treat written, asynchronous communication as the primary collaboration channel and reserve synchronous meetings for genuinely synchronous work. It is the practical answer for distributed teams whose overlap window is too narrow to support regular meetings — typically those spread across more than eight hours of UTC offset.