How time zones work: UTC, DST, and offsets explained

Most software treats time zones as a simple offset from UTC — "New York is UTC-5." This is accurate for about half the year and wrong for the other half. The full picture involves international standards, a continuously maintained database, political decisions, and a set of failure modes that have caused real-world system outages. Understanding how time zones actually work is prerequisite knowledge for any software that handles scheduling, logging, or cross-region communication.

UTC: the universal reference

Coordinated Universal Time (UTC) is the primary time standard used for civil timekeeping worldwide. It is defined by the International Telecommunication Union and maintained by an ensemble of atomic clocks. UTC does not observe daylight saving time and does not vary by location — it is the same number everywhere on Earth at any given moment.

UTC replaced Greenwich Mean Time (GMT) as the international standard in 1972. GMT is now a time zone identifier (UTC+0, no DST) rather than a time standard. The two coincide in value but differ in definition: GMT is based on solar observation at the Royal Observatory in Greenwich; UTC is based on atomic time with occasional leap-second corrections.

UTC offsets and their limits

A UTC offset expresses the difference between local civil time and UTC. UTC-5 means local time is 5 hours behind UTC; UTC+9 means 9 hours ahead. Offsets range from UTC-12 to UTC+14 (some Pacific island nations observe UTC+13 and UTC+14 to keep calendar alignment with their trading partners).

The critical limitation of offsets is that they are not stable over time. A location's offset changes at least twice a year in regions that observe daylight saving time, and can change permanently when a government changes its time zone policy. Storing a UTC offset alone — without the full time zone identifier — is insufficient for any date more than a few months in the future.

The IANA Time Zone Database

The authoritative source for time zone data is the IANA Time Zone Database, historically called the tz database or zoneinfo. It is maintained by a volunteer team under IANA authority and updated several times per year as governments announce time zone changes. Every major operating system and programming language runtime ships a copy of this database.

IANA time zone identifiers follow the format Region/City — America/New_York, Europe/London, Asia/Kolkata. Each identifier maps to a complete history of that location's UTC offsets and DST rules, not just the current offset. Using the full identifier rather than a bare offset allows software to correctly handle past timestamps, future timestamps near DST transitions, and changes to the time zone rules after a timestamp was recorded.

Daylight saving time as a rule, not a constant

Daylight saving time (DST) is a political policy, not a geophysical phenomenon. Countries, and sometimes individual regions within countries, independently decide whether to observe it, when it starts and ends, and how large the clock change is. The United States, most of Europe, and parts of Australia observe DST; China, Japan, India, most of Africa, and much of the rest of the world do not.

The DST rules for a given location are encoded in the IANA database as a set of transitions with effective dates. When the rules change — as they did in the United States in 2007 (the Energy Policy Act moved the start of DST from the first Sunday in April to the second Sunday in March) — the IANA database is updated, and software consuming the updated database automatically handles past and future dates correctly.

Common software errors

Several categories of time zone bugs appear consistently across software systems:

• Storing local time without a zone identifier. A timestamp of "2024-11-03 01:30:00" is ambiguous in the US Eastern time zone — that wall-clock time occurs twice on the day when clocks fall back from EDT to EST. Without the zone identifier or a UTC offset, you cannot know which occurrence is meant.
• Hardcoding offsets instead of zone identifiers. Code that assumes America/New_York = UTC-5 permanently will produce incorrect results for half the year. The offset changes; the identifier does not.
• Comparing local times across zones. "9 AM in London is 4 AM in New York" is true in winter but not in spring, when the US and UK transition to summer time on different dates, temporarily making the offset one hour different from its usual value.
• Not updating the tz database. Countries change their time zone rules with little notice. Operating systems and language runtimes ship tz database updates; systems that are not updated will have incorrect data for recently-changed zones.

RFC 3339 and timestamp representation

RFC 3339 defines a profile of ISO 8601 for internet timestamps: 2024-11-03T01:30:00-05:00. The UTC offset is included in the representation, making the timestamp unambiguous in absolute terms. For storage and interchange, this format — or plain UTC with a Z suffix — is the correct choice. Local time without an offset is appropriate only for display, and only when the display zone is known from context.

Practical recommendations

For software that handles scheduling or cross-region communication:

• Store timestamps in UTC. Convert to local time only at the display layer.
• Store the user's IANA time zone identifier (not their current UTC offset) for any future-scheduled events.
• Use a time library that is backed by the IANA database — Java's java.time, Python's zoneinfo, JavaScript's Temporal (now in most runtimes), Rust's chrono-tz.
• Keep the tz database current on all servers. Many Linux distributions ship it as a separate package (tzdata) that can be updated independently of the OS.