A time zone is not an offset

The distinction

An offset is a number: how far ahead of or behind UTC a clock is reading right now. A time zone is a set of rules: which offset applies, on which dates, in which place, including every time the rules have changed and every time they are scheduled to.

The offset is an output of the zone. Asking “what is the offset of this place?” is like asking “what is the temperature of this city?” — answerable only once you add when.

A worked example that runs the wrong way

The Chatham Islands are a useful case because they break two intuitions at once. Ask what offset Pacific/Chatham is running at:

• At 15 January 2026, 12:00 UTC — +13:45
• At 15 July 2026, 12:00 UTC — +12:45

The offset is larger in January. Anyone reasoning from a northern-hemisphere habit — summer means clocks forward, and January is winter — gets the sign backwards. The place did not move and the zone did not change; the calendar did. And the offset is three quarters of an hour off a whole number, which is a second intuition gone, covered in why some places are 45 minutes out.

What goes wrong when you store the number

Say a booking system records a future appointment as 2026-11-03 09:00 UTC+2. That looks precise. It is precise. It is also potentially wrong, because it has thrown away the only piece of information that could keep it correct: which place.

If the jurisdiction shifts its daylight-saving dates between now and November — and governments do this, sometimes with only weeks of notice — then the correct local time for that appointment changes, and the stored record has no way to know. It will keep resolving to the same instant, which is now the wrong instant for the person who has to be somewhere. Store Europe/Athens and the local wall time, and the answer re-derives itself correctly whenever the rules move.

The inverse mistake is subtler. If you are recording something that already happened — a log line, a transaction, a measurement — then the instant is the fact, and UTC is the right way to store it. Zones matter for intentions in the future; instants matter for events in the past. Mixing the two up is how systems end up with timestamps that shift when the rules change.

Why abbreviations make it worse

Zone abbreviations look like identifiers and are not. They are not unique, they are not standardised, and several of them mean different things in different countries — which means a string like CST cannot be resolved to an offset without already knowing the answer. A named zone from the IANA database (America/Chicago, Asia/Shanghai) has exactly one meaning, and that is the only reason it is safe to store.

How this site handles it

Every tool here works from a named zone, never a fixed number of hours, and reads the rules from your own device rather than shipping a copy that would go stale. The meeting planner steps through instants when it builds a grid, so a day that is 23 or 25 hours long comes out right by construction rather than by special case — see the hour that does not exist.

The reasoning behind reading rules from the platform rather than bundling them is set out on where our data comes from, and the testing that backs it on how we test.