How Time Zones Work: A Complete Guide to Global Time

Time zones look simple on a world map — a stack of vertical stripes, each one hour apart. The reality is messier, more interesting, and occasionally absurd. There are 38 distinct time zones in use today, not 24, and some of them differ by as little as 15 minutes. The rules that define them are updated several times a year by a small group of volunteers. Understanding how this system actually works will save you from scheduling mistakes that no amount of calendar software will catch for you.

The basic idea: 24 idealized slices

Earth rotates once every 24 hours, so the Sun crosses roughly 15 degrees of longitude every hour. In theory, you could divide the planet into 24 north-south bands, each 15 degrees wide, and assign each a time one hour apart from its neighbors. That was the vision of Canadian railway engineer Sandford Fleming, who proposed a worldwide system of standard time in the late 1870s. Before standard time, every town kept its own local solar time, which was a nightmare for train schedules. Fleming's idea caught on, and by 1929 most of the world had adopted standard time zones.

The theory is clean. The practice is not, because time zones are drawn by governments, not by geometry.

Why there are more than 24 time zones

Three things blow up the tidy 24-zone model:

• Political boundaries. Time zones follow country and provincial borders, not lines of longitude. China uses a single time zone (UTC+8) despite spanning five geographical zones, so that the entire country operates on Beijing time.
• Fractional offsets. India uses UTC+5:30, Nepal UTC+5:45, the Chatham Islands UTC+12:45. These zones do not align to whole hours, which means a naive "one zone per hour" tool will miscompute them.
• Daylight saving time. Many zones shift their offset twice a year, which means the same IANA zone name maps to two different UTC offsets depending on the date. Arizona does not shift; the Navajo Nation inside Arizona does; the Hopi Reservation inside the Navajo Nation does not. Time zones can be nested.

The result is that the actual number of distinct UTC offsets in use at any moment is closer to 38, and the rules that produce them change several times a year.

The IANA Time Zone Database

The rules that define every time zone — its standard offset, its daylight saving schedule, and the historical dates on which those rules changed — live in a single database known as the IANA Time Zone Database, or tzdata. It is maintained by a small group of volunteer editors, currently led by Paul Eggert, and it is the source of truth for essentially every operating system, language runtime, and library that handles time zones.

Each zone has a name in the form Area/Location, such as America/New_York, Europe/London, Asia/Kolkata, or Pacific/Auckland. The name refers to the largest city in the zone, not the country, because countries change but cities tend to keep their time rules. If you write America/New_York, the database knows that this zone was UTC−5 before 2007, when the US changed its daylight saving dates, and it can correctly compute historical times before that change. This is why storing the IANA zone name alongside a UTC timestamp matters for future events.

When a government announces a time-zone change — say, a country abolishing daylight saving time — the editors add an entry to the database, it is published, and downstream systems pick it up through their normal update channels. If your server is not updating tzdata, it will eventually produce wrong times for zones that have changed. For more on the global coordination layer that depends on this, see Global Time Coordination.

UTC offsets, in detail

A time zone's offset from UTC is written as UTC±HH:MM. A few things to keep straight:

• The offset is a property of the zone at a specific instant. "New York is UTC−5" is only true in winter. In summer it is UTC−4. The IANA zone name America/New_York resolves to the correct offset for any given date.
• East is positive, west is negative. Tokyo (UTC+9) is ahead of UTC; Los Angeles (UTC−8) is behind. The International Date Line sits around UTC±12, and crossing it changes the calendar date even though the local clock may read almost the same.
• The largest offset in use is UTC+14 (the Line Islands of Kiribati), which means those islands are a full 26 hours ahead of UTC−12 (Baker Island, uninhabited). The same planet, two days apart on the calendar.

If you need to convert between zones for a specific date, use a tool that reads the IANA database rather than doing the arithmetic yourself. Our Timezone Converter does exactly that, and our World Clock shows several zones side by side.

Daylight saving time: the complication that keeps on giving

About 70 countries observe daylight saving time (DST), shifting their clocks forward by (usually) one hour in summer and back in winter. The dates of those shifts vary by country, and they change. The US and Canada shift on the second Sunday of March and the first Sunday of November. The EU shifts on the last Sunday of March and the last Sunday of October. That means for a few weeks each year, the gap between US Eastern and Central European Time is five hours instead of six, and meetings that were convenient suddenly are not. We cover the history and impact of DST in detail in Daylight Saving Time Explained.

How to think about time zones when scheduling

1. Always pin a date. An offset without a date is meaningless, because DST may change it. "New York is UTC−5" is true from November to March and false the rest of the year.
2. Prefer IANA zone names. "EST" is ambiguous (US Eastern or Australian Eastern?). "America/New_York" is not.
3. Store UTC and the zone name, not the local time. For a future 9 AM meeting, store "09:00 in America/New_York" plus the UTC instant computed at scheduling time. If the zone rules change before the meeting, you can recompute.
4. Check both sides of a DST transition. A recurring meeting that works in February may break in April. Our Meeting Planner flags these transitions.

The bottom line

Time zones are a human invention layered on top of a physical reality, and the humans keep changing their minds. The system holds together because a single database — IANA's tzdata — is trusted by almost every computer on Earth, and because UTC gives that database a stable reference point to measure from. Once you accept that time zones are rules rather than geometry, and that the rules live in a database you should keep updated, the rest of international scheduling becomes a tractable problem.