Unix Timestamps: What That Giant Number Actually Means
September 29, 2026 · 5 min read
I'll be honest: the first time I saw 1698765432 sitting in a database column labeled created_at, I had no idea what I was looking at. A serial number? An ID? It turned out to be a date — November 1st, 2023, roughly. That ten-digit number is a Unix timestamp, and it's how an enormous amount of the software world records time. Once you learn to read them, you start seeing them in APIs, logs, JWT tokens, and file metadata everywhere.
Seconds since 1970. That's it.
A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment known as the epoch. Why 1970? Because that's roughly when Unix was born, and the convention stuck. Everything since is just counting seconds upward. Right now, as you read this, the timestamp is somewhere around 1.79 billion and climbing by one every second.
Why count seconds instead of storing something readable like 2026-09-29 14:30:00? Three reasons: it's compact (one integer), it's unambiguous (no arguing about date formats — is 03/04 March 4th or April 3rd?), and it's trivial to compare and do math with ("was A before B?" is just a < b; "how many hours apart?" is subtraction divided by 3600). Timezones, daylight saving, leap seconds — all that mess gets pushed to the display layer, where it belongs.
The milliseconds trap
Here's the gotcha that bites everyone exactly once. JavaScript's Date.now() returns milliseconds — 1759146600000, thirteen digits. Most other systems (Python's time.time() cast to int, PHP's time(), Unix date +%s) use seconds — ten digits.
Mix them up and you get nonsense: feed milliseconds into something expecting seconds and you land in the year 57700. Feed seconds into something expecting milliseconds and you get January 1970. The fix is easy once you know — multiply or divide by 1000 — but the debugging session before you figure it out is never fun. Count the digits: 10 = seconds, 13 = milliseconds. Tattoo it on your brain.
Timezones: where timestamps shine (and where they don't)
A timestamp is always UTC under the hood — it doesn't know about timezones at all. That's a feature: store the timestamp, and each user sees the time rendered in their zone. The classic bug is converting twice, or converting a timestamp that was already converted. Rule of thumb: store UTC, display local. Do the timezone conversion exactly once, at the moment you show the time to a human.
Daylight saving transitions are the other classic. If you schedule "every day at 2:30 AM" using raw timestamp arithmetic, you'll skip or double-fire on DST change days. For wall-clock scheduling, use a timezone-aware library, not raw second-counting.
The Year 2038 problem
Fun fact with real consequences: a signed 32-bit integer maxes out at 2,147,483,647 — which as a timestamp is January 19, 2038. After that, 32-bit systems overflow back to 1901. It's Y2K's less-famous sibling, and embedded systems, old databases, and file formats with 32-bit time fields will hit it. Most modern systems use 64-bit time already, so your laptop is fine — but if you work with firmware or legacy formats, it's worth knowing about. (And yes, some of us will be debugging this in 2037. Start stretching.)
Reading them at a glance
After a while you develop a feel: timestamps starting with 17... are "recent" (late 2024 through 2026), 16... is 2020–2023, 15... is 2017–2020. For anything precise, though, just convert. That's literally what converters are for — no one expects you to do epoch math in your head.