How to schedule across time zones

Scheduling across time zones is a small problem that creates a large volume of missed meetings, 3 AM wake-up calls, and “wait, was that your morning or ours?” Slack threads. Most of the trouble traces to four predictable failure modes: Daylight Saving Time, ambiguous abbreviations, half-hour and 45-minute offsets, and the asymmetric fairness problem of always making one side take the painful slot. This guide walks through the math, the tools, and the team conventions that actually work.

Always use UTC-anchored times for async announcements

Instead of writing “meeting at 3 PM,” write “meeting at 3 PM Pacific / 6 PM Eastern / 22:00 UTC / 11 PM London (next day 07:00 Tokyo)”. Three lines cost you fifteen seconds and remove the single biggest cause of missed meetings. Better: link to a permanent world-clock URL (everytimezone.com, timeanddate.com) that shows the moment across all zones live.

Daylight Saving Time — the silent meeting killer

DST is the biggest issue in scheduling because different regions switch on different dates:

US springs forward 2nd Sunday of March, falls back 1st Sunday of November.

Europe (most of it) changes on the last Sunday of March and last Sunday of October.

Australia changes in October and April (opposite months, opposite direction from the Northern Hemisphere).

Japan, most of Asia, most of Africa, most of South America, Arizona, Hawaii don’t observe DST at all.

The practical consequence: for 2–3 weeks each year in March/April and October/November, the normal offset between any two DST-observing regions is different than usual. A standing 9 AM ET / 2 PM UK meeting becomes 9 AM ET / 1 PM UK for the week the US has sprung forward and the UK hasn’t yet. Your calendar tool usually handles this correctly if you scheduled the meeting with a location-aware time zone. If you used “UTC+1” manually, it breaks.

Time zone abbreviations — ambiguous, avoid them

“CST” means Central Standard Time (US, UTC-6) or China Standard Time (UTC+8). “BST” is British Summer Time or Bangladesh Standard Time. “IST” is India, Israel, or Ireland. Always disambiguate with a city name (“Chicago time”) or a numeric offset (“UTC-6”).

Half-hour and 45-minute offsets catch everyone

India is UTC+5:30. Iran is UTC+3:30 (and changes half the year). Newfoundland is UTC-3:30. Nepal is UTC+5:45. Myanmar is UTC+6:30. Three-quarters of people scheduling across any of these zones eyeball the nearest whole hour and get it wrong. Always use a calendar tool or explicit conversion, never mental math.

Fair-rotation for recurring meetings

When two teams span a 6+ hour gap, someone is always taking it on the chin. The “fairness” default is to rotate whose morning / evening it is:

Rotation A: Odd-numbered weeks held in side-A’s morning, even-numbered weeks in side-B’s morning. Fair and predictable.

Rotation B: Stagger the meeting — meet every two weeks at one time, alternate weeks at another. Both sides suffer equally; neither suffers every week.

Async-default for most work: Reserve synchronous meetings for high-bandwidth discussions. Move status updates, reports, and decisions to written form so time zone becomes irrelevant. This is the biggest productivity unlock for globally-distributed teams.

The 6-hour rule for pain tolerance

Anything under a 6-hour offset can be scheduled in a civilized window for both parties (US East ↔ Europe is 5–6 hours, manageable). Over 8 hours (US West ↔ Europe at 9, US ↔ Asia at 12–15) means someone’s always either pre-7AM or post-8PM. At that point async is almost always the better option; daily sync becomes expensive enough that it should be reserved for weekly updates or explicit crisis response.

The three most common scheduling bugs

(1) Setting a time zone that doesn’t match your physical location. Digital nomad sets calendar to UTC, flies to Lisbon, invites a US team to a meeting. Everyone interprets “10 AM” differently. Fix: keep your calendar time zone set to where you’re physically sitting, update when you travel.

(2) Inviting someone via copy-pasted time. Calendar apps store meetings as absolute moments (UTC internally) and translate to each participant’s local time. Copy-pasting “2 PM” into an invite field for a person in another zone without the UI knowing what zone you meant is how you end up with meetings at 2 PM in the invitee’s zone when you meant 2 PM in yours.

(3) Not accounting for holidays in other regions.US Thanksgiving doesn’t exist in Europe. Chinese New Year wipes out most of Asia for a week. Golden Week in Japan is early May. Carnaval in Brazil is late Feb/early March. A globally-aware team checks all relevant regions’ holidays before locking in a launch date.

The right tool for the job

For one-off conversions, use the time zone converter. For recurring meetings, use your calendar’s native time-zone support (Google Calendar, Outlook both handle DST correctly if you pick a city-named zone). For broad team scheduling, use everytimezone.com or worldtimebuddy.com to see the whole team’s day at a glance.

Pair with the meeting cost calculator to decide when a 10-person sync across four time zones is actually worth scheduling vs moving to async, and the meeting agenda builder to keep the rare synchronous window high-leverage.