How Time Zones Actually Work (And Why They're Complicated)

For related fixes and guides, see our troubleshooting hub.

Most people think of time zones as simple offsets: New York is UTC-5, London is UTC+0, Tokyo is UTC+9. The reality is more interesting, and considerably more frustrating for anyone building software that handles time.

UTC: The Reference Point

UTC (Coordinated Universal Time) is the common reference. It's not a time zone it's a standard. Every time zone is defined as an offset from UTC.

A few things UTC is not:

• Not GMT. Greenwich Mean Time is an old solar time standard. UTC is based on atomic clocks. They're almost always the same, but not by definition.
• Not a time zone. UTC itself has no daylight saving time and no political boundaries.
• Not fixed to Earth's rotation. UTC occasionally adds "leap seconds" to stay within 0.9 seconds of solar time.

The Problem With Offsets Alone

If time zones were just fixed offsets, life would be simpler. But:

Daylight Saving Time (DST) changes the offset twice a year. New York is UTC-5 in winter (Eastern Standard Time) and UTC-4 in summer (Eastern Daylight Time). So "Eastern Time" is not a single fixed offset.

Countries switch DST dates. The US changes on the second Sunday of March. The EU changes on the last Sunday of October. Some countries changed their DST rules recently Chile moved its clocks in 2015. Russia stopped observing DST in 2014. North Korea changed its offset in 2015, then again in 2018.

Some offsets aren't whole hours. India is UTC+5:30. Nepal is UTC+5:45. Australia's central region is UTC+9:30 (or +10:30 during DST). Defining time zones as integer-hour offsets doesn't work.

Politicians change time zones. Samoas switched from UTC-11 to UTC+13 in 2011 jumping across the international date line to align economically with Australia. The date of December 30, 2011 simply didn't exist in Samoa.

IANA Time Zones: The Standard That Handles This

Rather than storing time zones as offsets, software uses the IANA Time Zone Database (also called the Olson database, after its creator).

Each time zone has a name like:

• America/New_York
• Europe/London
• Asia/Kolkata
• Pacific/Auckland
• Australia/Lord_Howe

These names map to a history of rules what offset applied when, when DST transitions happened, and how future transitions are expected to occur.

When you convert "3 PM on March 12, 2025 in America/New_York to Europe/Berlin", a correct time zone library looks up what offset each zone used on that specific date (accounting for DST transitions and historical rule changes), then does the math.

DST: The Twice-Annual Source of Bugs

Daylight Saving Time observance varies:

• United States and Canada: Most regions observe DST, switching in March and November
• Europe: Most countries observe DST, switching in March and October (but a week different from the US)
• Russia, China, India, Japan: Do not observe DST
• Australia: Observes DST in some states but not others (Queensland doesn't; New South Wales does)
• Arizona, US: Does not observe DST (except the Navajo Nation, which does)
• Portions of Indiana, US: Observed various different DST rules by county until 2006

The two-week window where the US and EU differ (US has already switched, EU hasn't yet, or vice versa) causes persistent scheduling confusion for international meetings. "Let's meet at 9 AM ET" means different things in March depending on which direction the clocks just moved and for which country.

Why "Add 5 Hours" Is Often Wrong

A common approach to time zone conversion: "Paris is 6 hours ahead of New York, so just add 6 hours."

This fails when:

• The conversion date spans a DST transition
• One zone observes DST, the other doesn't
• The offset has changed since you last checked

The correct approach: store and convert times using IANA zone names through a proper time zone library (Intl.DateTimeFormat in JavaScript, pytz or zoneinfo in Python, java.time in Java).

Reading Time Zone Strings

Common formats you'll encounter:

ISO 8601 with offset:

2025-11-15T14:30:00-05:00

This is November 15, 2025 at 2:30 PM, with the local time being UTC-5. The offset is literal it doesn't say which zone, just the offset at that moment.

UTC/Zulu time:

2025-11-15T19:30:00Z

The Z suffix means UTC. Same moment as the previous example (14:30 EST = 19:30 UTC).

Unqualified local time (dangerous):

2025-11-15 14:30

No offset, no zone. This is ambiguous. A time stored this way with no zone context is a future bug.

Best practice for storage: Always store timestamps in UTC. Convert to local time for display only.

The International Date Line

The Pacific Ocean is where the time zone map gets weird. Lines 180° east and west of UTC converge at the International Date Line but it's not a straight line. It zigzags to keep politically associated islands on the same calendar day.

This is why Samoa could switch from UTC-11 to UTC+13 without moving geographically it moved from just west of the date line to just east.

Half-Hour and 45-Minute Zones

Full-hour offset zones are the norm, but significant populations live in half-hour and 45-minute offset zones:

Any system that assumes time zones are whole-hour offsets will mishandle these.

Converting Between Zones

The time zone converter uses JavaScript's Intl.DateTimeFormat API, which references the IANA database. It handles DST transitions, historical rule changes, and non-integer offsets correctly.

Useful for:

• Scheduling international meetings
• Understanding what time a midnight UTC timestamp corresponds to locally
• Verifying UTC offset for a specific future date (remembering that DST changes it)

Time zones are one of those domains where intuitive approaches fail at the edges. The time zone converter handles the complexity so you don't have to remember which country's clocks changed last week.