03 - How Unix Time Actually Works (It's Just a Count Since 1970)
A Unix timestamp isn't a date. It's a COUNT — the number of seconds that have ticked by since one fixed
instant: 1970-01-01 00:00:00 UTC, the "Unix epoch." There's no year in it, no month, no time zone. Just
a running tally. The number 1700000000 isn't "November"; it's exactly 2023-11-14 22:13:20 UTC — and once
you can read the count, half of every confusing timestamp bug disappears.
This is layer 3 of the Time Stack — REPRESENTATION. Layers 0–2 got us a vibrating crystal, a hardware
clock, and the kernel's "now." This episode is where the machine writes that moment DOWN as a single
integer a program can store, compare, and send across a network.
WHAT WE COVER, BOTTOM-UP:
• THE EPOCH — every count needs a zero. Unix time's zero is 1970-01-01 00:00:00 UTC, exactly. We watch
1700000000 tick up one second at a time from that starting line.
• DECODING THE COUNT — seconds → days (÷86,400) → a calendar date. 1700000000 → 2023-11-14 22:13:20 UTC.
Pure arithmetic, no magic. And it converts both ways: count ↔ calendar.
• IT'S UTC, NOT LOCAL — the part everyone gets wrong. The stored number is UTC, full stop. New York and
Tokyo store the SAME number and apply a time-zone lens LATER (that's layer 6). The zone is a view.
• THE STRING FORM — when a human or an API needs it, the count becomes a standard string like
2023-11-14T22:13:20Z. That trailing Z means UTC. (ISO 8601 / RFC 3339 get their own episode, 03-03.)
• SECONDS vs MILLISECONDS — the classic off-by-1000 bug. Unix time_t counts SECONDS (1700000000).
JavaScript's Date.now() and Java's currentTimeMillis() count MILLIseconds (1700000000000). Feed one to
code expecting the other and your timestamp lands in 1970 or the year 56000.
• THE 2038 CLIFF — time_t is a SIGNED integer. A signed 32-bit count tops out at 2,147,483,647 seconds,
which is 2038-01-19 03:14:07 UTC. The very next second the sign bit flips and the count goes hugely
negative — 1901-12-13 20:45:52 UTC. It's Y2K, but in binary. The fix is total and boring: a 64-bit
time_t pushes the wall out about 292 billion years — effectively never.
THE ONE SUBTLE TRUTH WORTH SLOWING DOWN FOR: Unix time assumes every day is exactly 86,400 seconds. Real
UTC occasionally inserts a leap second — and Unix time just doesn't count it. So a Unix timestamp tracks
UTC, not the continuous atomic scale TAI. That's a known wart, baked into the definition on purpose; we
unpack leap seconds properly at layer 6.
By the end you'll read 1700000000 as a UTC instant on sight, convert count ↔ calendar in your head,
never confuse seconds with milliseconds again, and know exactly why 2038 matters and how it's already
mostly fixed.
One honest caveat that powers the whole series: a well-formed timestamp can still be WRONG. This layer
only defines how the number is written, not whether it's correct. A timestamp read off a drifting crystal
is a perfectly valid lie.
Next layer → Playlist 04: NTP keeps this count correct across every machine on Earth.
Time is a stack, not a number.
▶ Chapters
0:00 1700000000 — that's not a date, it's a count
0:32 L3: where "write the moment down" lives on the Time Stack
0:48 The epoch — every count needs a zero (1970-01-01 00:00:00 UTC)
1:04 Decoding the count — ÷86,400 → 2023-11-14 22:13:20 UTC
1:36 It's UTC, not local — the zone is applied later (New York / Tokyo)
1:52 count ↔ calendar — converting both directions
2:16 The string form — ISO 8601 (2023-11-14T22:13:20Z)
2:32 Seconds vs milliseconds — the off-by-1000 bug (time_t vs Date.now)
2:56 The wart — Unix time ignores leap seconds (86,400 s/day, UTC not TAI)
3:28 The 2038 cliff — a signed 32-bit count wraps to 1901
4:00 The fix — 64-bit time_t, ~292 billion years out (recap + handoff)
#UnixTime #EpochTime #Y2038 #ISO8601 #UTC #Timestamps #SystemsProgramming #KeepingTime