Working Across Time Zones: A Complete Guide for Remote Teams

Scheduling a meeting across time zones sounds simple until you have done it a few times. The person who said "let's meet at 9am my time" did not mention their time zone. Someone moved a meeting "an hour earlier" the week before a daylight saving transition, and it landed at the wrong time for half the team. A developer stored timestamps in local time and now the database is a mess of ambiguous entries.

Time zones are one of those systems that seem intuitive until they are not, and the edge cases cause real problems. This guide covers how the system works, where it breaks down, how remote teams can avoid the most common scheduling errors, and the standards that make working across time zones tractable.

You can use the BrowseryTools Timezone Converter — free, no sign-up, everything stays in your browser.

How Time Zones Work: UTC Offsets Explained

Time zones are defined as offsets from Coordinated Universal Time (UTC) — the modern successor to Greenwich Mean Time (GMT). UTC itself has no offset: UTC+0. Every other time zone is defined as UTC plus or minus some number of hours (and sometimes minutes).

New York is UTC-5 in winter (Eastern Standard Time) and UTC-4 in summer (Eastern Daylight Time). London is UTC+0 in winter and UTC+1 in summer (British Summer Time). Tokyo is UTC+9 year-round. Sydney shifts between UTC+10 and UTC+11 depending on whether it is observing daylight saving time — which runs from October to April in the Southern Hemisphere, opposite to the Northern Hemisphere.

Complicating matters further: not all time zone offsets are in whole hours. India is UTC+5:30. Nepal is UTC+5:45. Iran is UTC+3:30. Australia's Central Standard Time is UTC+9:30. These fractional offsets exist for historical, political, or geographical reasons and catch people off guard who assume all zones are on the hour.

Daylight Saving Time: Why It Makes Everything Harder

Daylight Saving Time (DST) is the practice of moving clocks forward one hour in spring and back one hour in autumn to shift daylight hours to the evening. It is observed by approximately 70 countries, ignored by the rest, and the transitions do not happen on the same date worldwide.

The US and Canada switch on the second Sunday in March and the first Sunday in November. Most of Europe switches on the last Sunday in March and the last Sunday in October. This creates a three-week window in March and a one-week window in November when the offset between, say, New York and London is different from what it is the rest of the year. A standing weekly call "at 2pm New York time" can land at 6pm London time for 48 weeks and 7pm for 4 weeks — catching people off guard every time.

Some places do not observe DST at all: Arizona (except the Navajo Nation), Hawaii, most of Africa, Japan, China, India, and much of Southeast Asia. The EU voted to abolish DST in 2019 but implementation has been deferred indefinitely. Until there is a permanent resolution, the complexity is not going away.

Why Scheduling Across Time Zones Is Error-Prone

The failure modes are well-documented:

• Assuming UTC offset is stable year-round — DST transitions mean the offset changes twice a year in most countries. A calendar invite created in January with a hard-coded UTC offset will be wrong after the March DST transition.
• "9am your time" — This phrase is ambiguous unless the speaker specifies the time zone explicitly. Their time zone, or your time zone? It is not always clear who is speaking.
• Calendar software inconsistency — Google Calendar, Outlook, and Apple Calendar all handle time zone display differently. An event created in one calendar app and shared via email does not always convert cleanly in the recipient's app, especially across different meeting invitation formats.
• Countries with non-standard offsets — Inviting someone in Kathmandu (UTC+5:45) or Tehran (UTC+3:30) to a meeting specified in whole-hour UTC will produce a fractional offset that many simple tools do not handle correctly.
• Date line crossings — A meeting at 9pm UTC on a Tuesday is Wednesday in Tokyo (UTC+9). Getting the date wrong when specifying meetings near midnight UTC is a common error.

Best Practices for Remote Team Scheduling

Teams that work across time zones have converged on several practices that dramatically reduce scheduling errors:

• Always specify time zone explicitly. Never say "3pm" without a time zone. "3pm UTC" is unambiguous. "3pm ET" is partially ambiguous (EST or EDT?). "3pm Eastern" is better but still ambiguous during transition weeks. "15:00 UTC" is completely unambiguous to anyone who knows their UTC offset.
• Use UTC as the team's reference time for internal communication. When discussing schedules internally, anchor everything to UTC. "The deploy is at 14:00 UTC" is something every team member can convert to their local time independently and correctly.
• Use tools that display multiple time zones simultaneously. A world clock showing UTC, each team member's current local time, and the offset makes it easy to check at a glance without mental arithmetic. The BrowseryTools Timezone Converter lets you compare multiple cities instantly.
• Schedule rotating "inconvenient" meetings. For globally distributed teams where no single time is convenient for everyone, rotate the inconvenient slot rather than requiring the same team members to always join at 7am or 10pm. Document the rotation so it is transparent.
• Avoid scheduling close to DST transition dates. In the two weeks around late October and late March, double-check offset assumptions before sending invites to international participants.

ISO 8601: The Datetime Format That Eliminates Ambiguity

ISO 8601 is an international standard for representing dates and times in a way that is unambiguous and sorts correctly as text. The format is:

YYYY-MM-DDTHH:MM:SSZ (or +HH:MM for offset)

• 2026-03-15T14:30:00Z — March 15, 2026, 2:30pm UTC
• 2026-03-15T14:30:00+05:30 — March 15, 2026, 2:30pm India Standard Time
• 2026-03-15T14:30:00-07:00 — March 15, 2026, 2:30pm Mountain Daylight Time

The "T" separates the date from the time. The trailing "Z" means UTC (Zulu time). A +/- offset specifies the local time and how far it is from UTC.

ISO 8601 is used in all modern APIs, web standards (HTML datetime attributes, HTTP headers), and most programming language date libraries. For human communication, the "YYYY-MM-DD" date format — even without the time component — is useful because it sorts correctly and is unambiguous internationally. "03/04/2026" is April 3rd in the US and March 4th in the UK. "2026-03-04" is unambiguous.

Timezone Handling in Code: Always Store UTC

The single most important rule for developers working with timestamps: store all timestamps in UTC in your database. Always. Without exception.

Storing timestamps in local time creates a class of bugs that are difficult to reproduce, hard to diagnose, and expensive to fix at scale:

• When your server changes time zones (as happens with cloud provider migrations), all historical timestamps are suddenly wrong
• DST transitions create ambiguous timestamps — 1:30am occurs twice on the day clocks fall back
• Sorting events chronologically becomes unreliable when timestamps mix different offsets
• Cross-timezone queries (find all events between midnight and midnight) become complex joins rather than simple range queries

The correct pattern: store UTC, display local. Accept user input in their local time, convert to UTC immediately, store UTC, convert back to user's local time for display. The database layer should never need to know anything about time zones.

Use the IANA timezone database (the "tz database" or "Olson database") for timezone data in code rather than maintaining UTC offsets manually. The IANA database is updated when countries change their DST rules or offsets — which happens more often than you would expect. Reference timezones by IANA identifier (e.g., "America/New_York", "Asia/Kolkata") not by offset (e.g., "UTC-5"), because identifiers correctly handle DST transitions while fixed offsets do not.