Time-zone cheatsheet for remote teams: the eight zones that cover 90% of meetings

Eight time zones cover most distributed-team meetings: Pacific (PST/PDT), Eastern (EST/EDT), Greenwich (GMT/BST), Central European (CET/CEST), India (IST), Japan (JST), Australian Eastern (AEST/AEDT), and New Zealand (NZST/NZDT). Memorising the offsets and DST behaviour for these zones eliminates 90% of the “wait, what time is this actually?” back-and-forth.

The cheat sheet

The DST traps that break recurring meetings

1. Three-week mis-aligned DST windows in spring

US DST starts on the second Sunday of March. EU DST starts on the last Sunday of March. For about three weeks each spring, US-to-EU meetings shift by an hour from their usual offset. A 9am EST / 3pm CET call becomes 9am EDT / 2pm CET — same NYC time, different Berlin time. Calendar apps usually get this right; humans recalculating in their head usually don’t.

2. Reversed seasons in the Southern Hemisphere

Australian DST runs October through April. NZ runs late September through early April. Both are oppositethe US/EU schedule. When New York “springs forward” in March, Sydney is about to “fall back.” A regular call between NY and Sydney shifts twice per US/EU transition and twice per AU/NZ transition — four adjustments per year, not two.

3. India and Japan don’t move

Neither observes DST. From the perspective of a US/EU colleague, the meeting time in India or Japan shifts twice a year even though nothing has changed there — the home office moved, not the remote one. This trips up spreadsheet-based scheduling that assumes a fixed offset.

4. The 24-hour gap between LA and Sydney

Pacific time and Australian Eastern time are ~18-19 hours apart depending on DST status. Most workdays don’t overlap at all. The narrow overlap window:

• LA 3pm = Sydney 8am next day (winter both)
• LA 4pm = Sydney 9am next day (US DST, AU winter)

Almost any LA-Sydney call lives in the LA-afternoon / Sydney-morning window. The reverse direction (Sydney afternoon / LA early morning) is brutal for the Pacific side.

The meeting-window math

Useful overlapping working hours for common pairings:

Best practices for cross-zone teams

• Pick one canonical time zonefor all published times. UTC is good if the team is genuinely distributed; the zone of the largest cohort is fine otherwise. Always include the offset (“3pm UTC (11am EDT)”).
• Rotate meeting pain. If half the team dialing in is at 8am and the other half is at 8pm, swap which half is which every other week. Long-running arrangements that always pin one team to evenings burn out that team.
• Asynchronous-by-default. The fewer meetings need to overlap, the less the time-zone math matters. Write decisions down; record video updates; treat synchronous time as the scarce resource it is.
• Use IANA namesin calendar invites (“America/New_York” not “EST”). IANA names track DST changes; abbreviations don’t. Calendar apps that store events by IANA name handle DST transitions correctly without manual edits.
• Watch the date.A 7pm Friday call in California is 12pm Saturday in Sydney. Calendars handle the date math — humans guessing don’t.

Tools that actually help

Convertitive’s time-zone converter renders any time across 28 major zones with DST handled automatically by the browser’s IANA database. The world clock gives a live overview for picking meeting windows. Calendar apps (Google Calendar, Outlook, Cal.com) all let you display secondary time zones in the side rail — turn it on once and forget it.

For the conceptual background on UTC, GMT, and IANA timezones, see UTC vs GMT and the IANA timezone glossary entry.

Walkthrough: scheduling a four-zone all-hands

A 60-minute company-wide meeting with cohorts in San Francisco (PST/PDT), New York (EST/EDT), London (GMT/BST) and Bangalore (IST). Target date: Thursday, 7 May 2026.

• DST status on 2026-05-07: US is on PDT (UTC-7) / EDT (UTC-4). UK is on BST (UTC+1). India is UTC+5:30 year-round.
• Express the meeting in UTC: 15:00 UTC.
• Per-cohort clock:
  • San Francisco: 8:00 PDT (early but workable)
  • New York: 11:00 EDT (prime)
  • London: 16:00 BST (late afternoon)
  • Bangalore: 20:30 IST (after-dinner — the price of including India in a US-centric call)
• Calendar invite format (RFC 9557 style):2026-05-07T15:00:00Z[Etc/UTC]with secondary times listed in the description for each cohort. The calendar client renders the user’s local time automatically; the explicit Z removes ambiguity.
• Rotate next month: a 7:00 UTC slot reverses the pain — Bangalore at 12:30 IST is prime, San Francisco at midnight is brutal. The all-hands cadence should rotate so no single cohort is always sacrificed.

Common mistakes

• Writing “EST” year-round.New York is on EDT (UTC-4) for ~8 months of the year. A calendar invite that says “3 PM EST” in July is silently 4 PM EDT — or it’s wrong, depending on who you ask. Use IANA names (America/New_York) or UTC with offset.
• Confusing GMT and UTC.They differ by fractions of a second (leap-second handling). For human scheduling they’re identical, but London is NOT on GMT in summer — it’s on BST. “GMT” in a July invite is technically wrong.
• Manually computing across the dateline.A Friday 4 PM Sydney meeting is Friday 11 PM the previous day in San Francisco. Date math by hand fails in both directions; let the calendar render it.
• Storing event times in local time.Apps that store “9:00” with a separate timezone field break the moment the timezone’s DST rules change (the IANA database releases ~5 updates per year). Store as UTC instant plus the original IANA name; render locally.
• Asia/Calcutta vs Asia/Kolkata. Both work as aliases, but mixing them in calendars across systems can cause sync glitches. Use the canonical Asia/Kolkata form.

Edge cases the cheatsheet doesn’t cover

• Arizona (mostly) doesn’t observe DST.Phoenix is on MST year-round; the Navajo Nation observes DST. A “Mountain Time” meeting can be in two different actual times depending on which county.
• Lord Howe Island (Australia) uses a 30-minute DST offset — UTC+10:30 winter, UTC+11 summer. Fractional offsets exist in Newfoundland (UTC-3:30), Iran (UTC+3:30), Afghanistan (UTC+4:30), India (UTC+5:30), Nepal (UTC+5:45), Myanmar (UTC+6:30), and the Chatham Islands (UTC+12:45).
• EU DST may end any year now. The EU parliament voted in 2019 to end seasonal clock changes; adoption has been delayed indefinitely. When it finally happens, member states pick standard or summer time permanently — different choices will create new intra-EU offsets.
• Same-day flights crossing the date line.A flight from Auckland to Honolulu lands “before” it took off in local-time terms. Calendar apps handle this; humans estimating arrival times don’t.
• Historical timestamps.“9 AM in Berlin on 1942-04-15” needs the historical timezone rules (CEST, with wartime CEMT-equivalent variations). IANA encodes these — naive UTC offset arithmetic doesn’t.

Sources: IANA tz database (2026a); EU Directive 2000/84/EC (summer-time arrangements); US Energy Policy Act of 2005 (modern US DST schedule); RFC 9557 (IXDTF).