工具 指南

Working Across Time Zones: A Practical Guide to Global Scheduling

How time zones work, why UTC matters, the DST trap, and how to schedule meetings without accidentally waking someone up at 3 AM.

BoxTool Editorial 最后更新: 五月 27

Working Across Time Zones: A Practical Guide

Global teams, remote work, and international launches have made timezone math a daily skill. Yet it remains surprisingly easy to get wrong — especially when daylight saving time shifts don't align between countries. This guide covers everything you need to coordinate across time zones reliably.

How Time Zones Work

The Earth rotates 360° every 24 hours, making 15° of longitude equal to one hour. The prime meridian (0°) at Greenwich, England, defines UTC (Coordinated Universal Time) — the world's time standard.

Time zones are expressed as offsets from UTC: UTC+5:30 (India), UTC-5 (US Eastern Standard Time), UTC+9 (Japan), etc.

But it's not purely geographic. Countries choose their time zones for political and economic reasons. China spans five natural time zones but uses a single UTC+8 for national unity. India uses UTC+5:30 (a half-hour offset) for historical reasons. Parts of Australia use 30-minute and 45-minute offsets.

UTC: The One True Reference

UTC is the backbone of all time zone conversions. It never changes — no daylight saving, no political adjustments. All other time zones are expressed as offsets from UTC.

When logging events, scheduling deployments, storing timestamps in databases, or writing API responses, always use UTC:

# ✅ Store and log in UTC
2026-05-28T09:30:00Z        (the Z means UTC)
2026-05-28T09:30:00+00:00   (explicit UTC offset)

# ❌ Never store local time without the offset
2026-05-28 09:30:00         (which timezone??)

The moment you store a time without a timezone, you've introduced ambiguity. This causes bugs during DST transitions and server migrations.

Daylight Saving Time: The Trap

Daylight Saving Time (DST) shifts clocks forward in spring and back in autumn — but different countries do this on different dates, and some don't do it at all.

Key differences in 2026: | Region | DST period | |--------|-----------| | US / Canada | Second Sunday in March → First Sunday in November | | European Union | Last Sunday in March → Last Sunday in October | | Australia (most states) | First Sunday in October → First Sunday in April (Southern Hemisphere) | | Japan | No DST | | India | No DST | | China | No DST |

The dangerous gap: When US clocks change (in March) but European clocks haven't yet (or vice versa), a New York → London meeting slot that "worked" at 9 AM EST last week may now be at a different relative time. The gap is usually 1–2 weeks twice a year.

Always use named time zones (like America/New_York) rather than fixed offsets (UTC-5) in scheduling software, because named zones account for DST automatically.

The Most Common Time Zones

City Time Zone UTC Offset (Standard)
Los Angeles America/Los_Angeles UTC−8 (PST) / UTC−7 (PDT)
New York America/New_York UTC−5 (EST) / UTC−4 (EDT)
São Paulo America/Sao_Paulo UTC−3
London Europe/London UTC+0 (GMT) / UTC+1 (BST)
Paris / Berlin Europe/Paris UTC+1 (CET) / UTC+2 (CEST)
Dubai Asia/Dubai UTC+4 (no DST)
Mumbai Asia/Kolkata UTC+5:30 (no DST)
Singapore Asia/Singapore UTC+8 (no DST)
Seoul / Tokyo Asia/Seoul UTC+9 (no DST)
Sydney Australia/Sydney UTC+10 (AEST) / UTC+11 (AEDT)

Finding the Overlap Window

When scheduling with global teams, the challenge is finding a time that's reasonable for everyone (not 3 AM or 11 PM).

Reasonable working hours: 8 AM – 7 PM local time

For a meeting between Seoul and New York: - Seoul: 9 AM–7 PM (KST = UTC+9) - New York: 9 AM–7 PM (EST = UTC-5) - Gap: 14 hours - Seoul 9 AM = New York 8 PM (previous day) — outside reasonable hours - Result: No genuine overlap. Someone has to compromise. A 8 AM Seoul call = 7 PM New York (just barely works).

Standard overlap challenges:

Pair Overlap Notes
NY ↔ London 2–5 PM London / 9 AM–12 PM NY Usually workable
NY ↔ Seoul Very limited Seoul mornings = NY late evenings
London ↔ Singapore Limited Singapore afternoons = London mornings
San Francisco ↔ Berlin 9 AM–noon Berlin = midnight–3 AM SF Difficult

Rule of thumb: When the difference is more than 10 hours, someone will always be at the edge of their working day. Rotate the inconvenient slot.

Best Practices for Global Teams

  1. Use UTC in all technical contexts: logs, database timestamps, API responses. Convert to local time only in the UI.

  2. Specify the time zone in all meeting invitations: "3 PM EST" is ambiguous during DST gaps; "3 PM New York time" or 15:00 America/New_York is unambiguous.

  3. Use calendar tools that auto-convert: Google Calendar, Outlook, and Zoom all show meeting times in the viewer's local time zone automatically.

  4. Rotate meeting times: if you always schedule at 9 AM London time, San Francisco is always at 1 AM. Rotate so the inconvenience is shared.

  5. Be aware of public holidays: a time that "works" mathematically may fall on a local holiday. Factor this into international launches.


Convert between any two time zones: Timezone Converter →

试用工具

打开工具
{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}