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
-
Use UTC in all technical contexts: logs, database timestamps, API responses. Convert to local time only in the UI.
-
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_Yorkis unambiguous. -
Use calendar tools that auto-convert: Google Calendar, Outlook, and Zoom all show meeting times in the viewer's local time zone automatically.
-
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.
-
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 →
Probar la herramienta
Abrir herramienta