Time-zone rules change with politics; year-spanning conversion cannot assume a frozen map

What it is

How many hours a city sits ahead of UTC, and on which night it jumps the clock, is not a geographic constant. It is statute. Historical zone rules change. A place that does not observe daylight saving this year may have observed it ten years ago; the standard offset itself can be moved by a legislature. Converting a 2010 local clock face with a 2026 rule table yields the wrong instant. Year-spanning conversion has to carry the rules that were in force that year. A single table cannot be assumed for life.

Why it happens

A rule table (the IANA time zone database and kin) slices each zone into periods: from which date the offset is this, whether DST applies, from which date to which. Converting a past local clock face means finding which slice it fell in, then using that slice’s offset. Using the “current slice” to decode a historical face rewrites the cells that were on the wall at the time. Future recurrences are more brittle: a statute may be published only shortly before the event, and the table used at expansion may not be the table in force at occurrence.

If client, server and database each hug a different table version, one record yields three instants. The bug looks like “wrong zone” and is actually a political version skew of the table. The table also needs an update channel: a country announces DST is cancelled, and a product still on the old table will miscompute every local face on the day the statute takes effect.

Where it stops holding

Relative time that only cares about the next few hours, never stepping on a historical slice, is untouched by rule change. A past event already stored as an absolute instant no longer depends on the table to recover “which instant it was” — the table only still affects “which clock face to draw”. What actually breaks is data that recorded only a local face plus a zone name and never the instant, and series that have not yet occurred and still expand from a clock-face rule. A test environment frozen on one table will never see a statute change, and will file production conversion errors as flukes.

Applying it

• When converting any year-spanning local clock face, use the historical slice that date belongs to, not “the current offset”.
• Running services must be able to update the rule table, and after an update must re-expand recurrences that have not yet occurred, rather than keep old instants.
• Client, server and batch jobs should use one table version. Put the version in observability, so “the day we miscomputed” can be lined up with “a new statute shipped”.
• How to check: take a zone with a known statute change (DST on then off, or a moved standard offset). Convert a pre-change local face with “the slice then” and with “the slice today”; the two instants should be deliberately different. After a table update, not-yet-occurred series should recompute; historical events archived as instants must not have those instants rewritten by the table update.

Related

• Same group: I4.08.1 Store time in an absolute standard; convert to local only at display · I4.08.2 Recurring events that cross DST must recompute local clock time, not a fixed offset · I4.08.4 After the user changes zone, past records must keep the same absolute instant
• Nearby: I4.05 Time zones · S2.01 Date and Time Formats
• Search terms: tz database · IANA timezone · historical offset