06 - Store UTC, Render Local — the One Time-Zone Rule Every Dev Should Know
At 1:30 in the morning, a cron job ran. Fifty-nine minutes later, it ran AGAIN — same job, same 1:30.
Nobody scheduled it twice. It was the night the clocks went back, and 01:30 local time happened twice.
Here's the thing your machine already knew and your code forgot: a computer keeps exactly ONE number —
UTC — and a wall clock is just a VIEW of it, computed with an offset and a political ruleset that can
repeat an hour, or delete one. This is L6 of the Time Stack: HUMAN TIME — the layer where physics hands
off to politics, and the one number becomes the local time a person actually reads.
WHAT A TIME ZONE REALLY IS (it's two things, not one):
• AN OFFSET from UTC — e.g. Asia/Kolkata is UTC +05:30. Add the offset, get the local reading. If that
were the whole story, time zones would be trivial.
• A POLITICAL RULESET — when daylight saving starts and ends, whether it applies at all, and the one-off
changes governments make. America/New_York is UTC −05:00 in winter and −04:00 in summer. The offset
MOVED — and nobody touched the UTC number underneath.
WHERE THE RULES LIVE: the IANA TIME-ZONE DATABASE (the "tz database," tzdata). It records every zone, its
current rules, AND its entire history of changes, and it's updated several times a year because the rules
are political. Always name a zone by its IANA ID (America/New_York), never by an abbreviation (EST) —
abbreviations are ambiguous, carry no DST history, and aren't even globally unique.
WHY DST BREAKS THINGS (two failure modes, keep them straight):
• SPRING FORWARD → an hour VANISHES. The clock jumps 01:59 → 03:00, so 02:30 local simply does not exist.
Schedule something for 02:30 that night and you've asked for a moment that never happens.
• FALL BACK → an hour REPEATS. The clock falls 01:59 → 01:00, so 01:30 happens TWICE, sixty minutes
apart. "Run at 1:30 local" is now a question — which 1:30? That's exactly why the cron fired twice.
THE ONE RULE THAT MAKES IT ALL GO AWAY: STORE UTC, RENDER LOCAL. Keep UTC everywhere it matters — your
database, your business logic, your logs, the wire between services. Convert to a local wall clock ONLY at
the very edge, purely so a human can read it. Time zones become a display concern, not a data concern —
and an entire category of bugs disappears. The ambiguity was never in the number; you create it the moment
you store a wall clock instead of an instant.
By the end you'll be able to explain a time zone as an offset PLUS a ruleset, say why the IANA tz database
exists and why your servers need its updates, draw the spring-forward gap and the fall-back repeat from
memory, and apply the one rule that turns time zones into a display-only problem.
A precision we keep honest: UTC is a STANDARD; GMT is a TIME ZONE (the UK's winter wall clock,
Europe/London at +00:00). Keep UTC ≠ GMT ≠ TAI ≠ GPS distinct (full untangle in 06-04). And UTC hides one
more tick — the leap second — which gets its own episode (06-02); we don't quote a leap-second count here
because it drifts and is dated on screen there.
Next layer → Playlist 07 (Distributed Time): what happens when even one UTC number isn't enough and
machines must agree on the ORDER of events.
Time is a stack, not a number.
▶ Chapters
0:00 L6 Human Time — the machine keeps ONE number (UTC)
0:32 1:30 AM, twice — the cron job nobody scheduled twice
0:48 Underneath, it's the same ONE number: UTC
1:04 Humans read a local wall clock, not UTC
1:20 One number, many wall clocks — the fan-out
1:36 Part one of a time zone: the offset (UTC +05:30)
1:52 Part two: a political ruleset that changes by law (DST)
2:08 Where the rules live: the IANA tz database (tzdata)
2:32 Name zones by IANA ID, never by abbreviation (America/New_York, not EST)
2:48 Spring forward — the hour that VANISHES (02:30 never exists)
3:04 Fall back — the hour that REPEATS (why the cron ran twice)
3:28 The fix: store UTC (the cron now fires once)
3:52 Store UTC, render local — convert only at the edge
4:32 Recap — and two loose threads (leap seconds 06-02, UTC vs TAI/GPS/GMT 06-04)
#KeepingTime #UTC #TimeZones #DST #StoreUTCRenderLocal #tzdatabase #SystemsProgramming #DateTime