TL;DR
- ▸Time zones are a political artefact layered on top of UTC. They change. Daylight saving rules change. Countries adopt or abandon DST at short notice.
- ▸Store times as UTC. Convert to a time zone only at the user-facing edge. Keep tzdata updated. Don't try to invent your own DST handling.
- ▸For audit-significant times, capture both UTC and the originating time zone metadata so the conversion can be reproduced later.
Time zones change. UTC doesn't.
Every distributed system that handles human-readable times sooner or later runs into the fact that time zones are a political artefact, not a physical one. They change. Daylight saving rules change. Countries adopt or abandon DST at short notice. Some time zones have offsets that aren't whole hours (Newfoundland is UTC-3:30; India is UTC+5:30; Nepal is UTC+5:45). Some places observe time changes that align with the lunar calendar rather than the solar one. Some places have multiple legal time zones in the same country (China officially uses one but practically uses several).
The IANA tzdata database tracks all of this and is the canonical source for time zone information. Every operating system and programming language environment depends on tzdata, which means every system that depends on time zones has to update tzdata regularly to stay current. Failing to update tzdata is a common silent failure that surfaces during the next time zone transition.
What to do about it
Three rules. Store times as UTC internally — never store local times as the canonical representation. Convert to a time zone only at the user-facing edge of the system, where the human reader needs to see local time. And keep tzdata updated across the fleet on a regular cadence (tzdata releases happen roughly quarterly).
For times that have legal or audit significance — financial timestamps, legal documents, regulatory filings — capture both the UTC time and the originating time zone metadata. This way the conversion can be reproduced reliably later, even if the originating time zone's rules change between the event and the audit. The cost of capturing the metadata is trivial; the cost of not having it is potentially significant when a regulator asks.
Frequently asked questions
What is tzdata?+
Should I store times as UTC or local time?+
Do I need to keep tzdata updated?+
Related reading
Blog · Foundations
Timekeeping: History and Technology
A short history of timekeeping — from sundials to caesium fountains and beyond — and how each advance in physical clock technology has reshaped what we can do with precision time.
Blog · Foundations
Atomic Clocks and GPS Timing
How atomic clocks define UTC, how GPS distributes that time globally, and what the relationship between the two means for precision timing infrastructure on the ground.