Time Zones, UTC and DST, Explained
By Mark Fulton · 2026-08-09 · 2 min read
Every scheduling disaster between cities comes from the same misunderstanding: treating a city's time as a fixed offset. "London is UTC+0" is true for half the year. The other half it's UTC+1, and the switch dates are politics, not astronomy.
UTC is the anchor
Coordinated Universal Time (UTC) is the world's reference clock, maintained by the BIPM from a weighted average of atomic clocks around the world. Every civil time on Earth is defined as UTC plus or minus an offset. UTC itself never observes daylight saving and never changes — which is exactly why it's the anchor everything else is described against.
City time is a database
A city's offset changes over time — seasonally (DST) and historically (governments move zones, abolish DST, adopt it again). The world's reference for all of it is the IANA Time Zone Database: a maintained dataset of named zones like America/New_York and Asia/Kolkata, each carrying its complete rule history. Your phone, your laptop, and your browser all ship a copy, updated whenever some parliament somewhere changes the rules — which happens several times a year.
That's why a good world clock stores zone names, not offsets. Given Europe/London, the tz database answers "what's the offset right now" correctly on both sides of the DST switch, forever, with no updates from us.
Why DST breaks recurring meetings
The trap: DST transitions are not synchronized between countries.
| Period | New York vs London |
|---|---|
| Most of the year | 5 hours apart |
| ~2 weeks in March | 4 hours apart (US springs forward first) |
| ~1 week in Oct/Nov | 4 hours apart (UK falls back first) |
A "9am NY / 2pm London" weekly call silently becomes 9am/1pm during the mismatch windows. Whoever anchored the meeting in their own local time is fine; the other side is an hour off. The fix is to anchor meetings in one named zone and let everyone else's calendar convert — and, before proposing a time, glance at a board showing both cities' current offsets rather than the offsets you remember.
Some offsets aren't whole hours at all — India runs at UTC+5:30 and Nepal at UTC+5:45 — one more reason arithmetic-by-memory loses to a database lookup every time.
Sources
- BIPM, Time metrology and UTC
- IANA, Time Zone Database