Fundamentals

Timezones Are a Political Problem, Not Just a Technical One

The map of timezones isn't fixed by geography. It's redrawn, sometimes with only months of notice, by decisions that have nothing to do with the sun.

It's tempting to think of timezones as a fixed grid, neatly following lines of longitude every 15 degrees. In reality, timezone boundaries are drawn by governments, and they follow national borders, economic convenience, and politics far more often than they follow the actual position of the sun.

Real examples, not hypotheticals

China spans a longitude range that would naturally cover five geographic timezones, but the entire country uses a single official time, Beijing time — a political choice for national unity, not a geographic one. Spain, geographically in line with the UK, uses Central European Time instead of matching London, a legacy of a decision made during World War II that was never reversed. Samoa jumped an entire day in 2011, skipping December 30th completely, to align its trading week with Australia and New Zealand instead of the United States.

Countries change their minds, with short notice

Daylight saving rules aren't stable either. Countries have started, stopped, and restarted observing DST within a matter of years, sometimes announcing the change only months before it takes effect. This is precisely why the IANA Time Zone Database — the dataset your browser, phone, and server operating system all rely on — gets updated multiple times a year, not because the underlying science changed, but because some government somewhere changed a law.

What this means for anyone writing software

It means hardcoding UTC offsets is a bug waiting to happen. "UTC+2" isn't a timezone — it's the current offset for some zone at some moment, and it will be wrong the next time that region's DST rules shift or a boundary gets redrawn. Software should store and reference actual IANA timezone identifiers — Europe/Madrid, Pacific/Apia — and let an updated timezone database resolve the correct offset for any given date, rather than baking in a number that's only accurate until the next policy change.

Curious what a specific abbreviation like IST or CST actually refers to, and where the ambiguity comes from? See the Timezone Abbreviation Lookup.

Related

Related tools & reading