Every distributed team eventually breaks something on timezones. The failures aren't "we didn't know timezones exist" — they're a short list of predictable process mistakes that quietly wreck async work.
A distributed team can get almost everything right — clear docs, good handoffs, generous overlap — and still lose a day to a calendar invite that fired an hour off. Timezone failures on global teams aren't ignorance; everyone knows timezones exist. They're a handful of specific, repeatable process mistakes, and because each one looks small, they keep happening on team after team. Here are the ones that actually cost you.
Store UTC, display local — and the one exception
The foundational rule: store every timestamp as UTC (or a Unix timestamp), and convert to the viewer's local time only for display. Do that and most timezone bugs never form. But there's a genuine exception that trips people who over-apply the rule: scheduled events where the intended time is a local time. A recurring 9 a.m. London standup should stay 9 a.m. London after a daylight-saving change — even though its UTC time shifts by an hour. Store that as "9 a.m. Europe/London," not as a fixed UTC instant, or the meeting drifts twice a year. Store-UTC is right for "when did this happen"; local-intent is right for "when should this recur."
The DST gap that breaks standups
Here's the one almost nobody plans for: regions don't change their clocks on the same day. The EU and the US shift their clocks weeks apart in spring and autumn. For those in-between weeks, the offset between, say, New York and London is not the one your team memorised — it's an hour off for everyone who fixed the standup time in their head as "always 5 hours." A meeting that's normally 2 p.m. UTC silently becomes 3 p.m. UTC for one side. Calendar tools that store the event as a local recurrence handle this correctly; humans doing the math from memory do not. When a recurring cross-region meeting suddenly feels an hour wrong for a few weeks each spring, this is why.
ISO 8601 without an offset is a landmine
A timestamp like 2026-06-06T09:00:00+02:00 is an unambiguous moment. The same string without the offset — 2026-06-06T09:00:00 — is a bug waiting to happen, because different systems assume different things about what timezone it means. The internet timestamp standard is explicit that the offset carries real meaning:
"The offset between local time and UTC is often useful information. For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response."
— IETF RFC 3339, "Date and Time on the Internet: Timestamps"
The rule for any timestamp that crosses a system boundary: always include the offset or a Z. A naked local time is the timezone equivalent of an unlabelled unit.
The "noon everywhere" fallacy
There is no globally fair meeting time, and pretending otherwise burns goodwill. "Noon" for whom? Noon in London is early morning in California and late evening in Tokyo — someone is always inconvenienced. The honest answer for a genuinely global team isn't a clever single time; it's rotation, so the pain is shared rather than always dumped on the same region. Naming that explicitly beats quietly scheduling everything in the organiser's own comfortable hours and wondering why one timezone keeps going quiet.
Scheduled jobs need an explicit timezone
The same failure shows up in automation. A job scheduled for "9 a.m." without a stated timezone runs in the server's timezone, which is rarely the one anyone meant, and drifts relative to local time when regional DST changes but the server's clock doesn't. For any human-meaningful schedule, state the timezone explicitly (modern schedulers support it) or convert the intended local time to UTC deliberately. Don't let the server's accident of configuration decide when your reports go out.
The IANA timezone database
Behind every correct timezone conversion is the IANA timezone database (often called "tz" or "Olson database"), which maps identifiers like America/New_York or Europe/London to their full history of UTC offsets, including every DST transition. Using these identifiers instead of fixed UTC offsets is critical for recurring events: +05:00 is an offset that's true right now but may not be after the next DST change, while Asia/Kolkata is a timezone that resolves to the correct offset for any date, past or future. Libraries like Intl.DateTimeFormat in JavaScript, pytz or zoneinfo in Python, and java.time.ZoneId in Java all use IANA identifiers. When someone says "store the timezone," they mean the IANA identifier, not the offset — the offset is a snapshot, the identifier is the source of truth.
Countries that change their timezone rules
Timezone rules are not fixed. Countries change their DST schedules, abolish DST entirely, or shift their base UTC offset — and this happens more often than most developers expect. Russia has abolished and reinstated DST multiple times. Egypt, Turkey, and Morocco have all changed their DST rules in the last decade. The EU has been debating abolishing seasonal clock changes since 2019. When a country changes its rules, the IANA database is updated, and any application that bundles or caches timezone data needs to pick up the new version. Applications that embed a timezone database at build time and never update it will start computing wrong offsets the moment a rule changes — and the bug manifests as meetings at the wrong time, reports with shifted timestamps, and scheduled jobs firing an hour off. Treat the timezone database as a dependency that needs regular updates, not as a static reference.
Team-facing timezone practices that actually work
Beyond the technical plumbing, a few team practices prevent the most common timezone-related friction in distributed work. First, always include the timezone when writing a time in any shared document, chat message, or ticket — "3 PM" is ambiguous, "3 PM CET" is not. Second, keep a shared team-hours dashboard that shows each member's current local time, updated for DST — this removes the mental math that causes scheduling errors. Third, for asynchronous handoffs, use an explicit "end of day" convention with a timezone attached: "EOD Friday Pacific" is unambiguous, "EOD Friday" invites misinterpretation across a 17-hour span. Fourth, run calendar invites from a tool that stores recurring events as local-intent times (most modern calendar apps do this), and resist the urge to manually adjust invite times around DST transitions — the calendar should handle that, and manual overrides usually cause double-corrections.
Make the conversions visible
Most of these errors are really "someone did timezone math in their head and got it wrong." Take the math out of your head. A timezone converter settles "what time is the standup for everyone" — including across a DST gap — without guesswork. A timestamp converter turns Unix times and ISO 8601 strings into each other so you can confirm what an offset-less timestamp actually resolves to. And a date calculator handles DST-aware arithmetic when you're working out "three business days from now" across regions. Async works when the team stops trusting mental timezone math and starts checking it.
← All articles