Beneath almost every digital timestamp — the “sent at” on your messages, the modified date on your files, the expiry on a security certificate — sits a single, enormous number: the count of seconds since 00:00:00 UTC on 1 January 1970. This is Unix time, and it is arguably the most successful standard in computing history.
Why 1970? Why seconds? Why UTC? And what is the infamous Year 2038 problem — plus the strange business of leap seconds, which Unix time politely pretends do not exist? This article unpacks the number that runs the internet's clocks.
What Unix time is
Unix time (also called POSIX time or epoch time) is beautifully simple: it is the number of seconds that have elapsed since the Unix epoch — midnight at the start of 1 January 1970, Coordinated Universal Time. At the time of writing, that number is around 1.75 billion and climbing by one every second.
Storing time as a single integer has enormous practical advantages. Comparing two moments is just comparing two numbers — no parsing month names, no time-zone tables. Sorting events, computing durations and expiring tokens all become trivial arithmetic. That is why databases, file systems, APIs and authentication tokens (like JWT expiry claims) overwhelmingly store time this way and convert to human-readable form only at display.
Why 1 January 1970?
The date was chosen by the engineers building Unix at Bell Labs in the early 1970s. They needed a “time zero” and picked a recent, round-feeling date near the system's birth — 1 January 1970 was close enough to be practical and far enough back to cover anything the system would plausibly date. A 32-bit signed integer counting seconds from that point spans about 136 years, which seemed like plenty.
It was an arbitrary choice that became a universal one. So much software adopted the convention that the epoch is now baked into programming languages, operating systems and network protocols alike — a reminder that in computing, being first and simple often beats being perfect.
UTC: the one true clock
Unix time counts seconds in Coordinated Universal Time, the world's civil time standard, which has no daylight saving and no offsets. This single decision eliminates an entire category of bugs: a timestamp means the same physical instant everywhere on Earth, whether it was recorded in Karachi, London or Sydney.
Human-friendly display is a separate step. Your phone converts the stored number into your local time zone when showing it — which is why a message timestamp looks right when you travel. The classic time-zone bug (an event stored in local time, then misread after a DST change) simply cannot happen when the stored value is zone-free. If you take one lesson from this article: store UTC, display local.
- Unix time is always UTC — never local time.
- Daylight saving never touches a timestamp.
- Display converts to local zones; storage never does.
The Year 2038 problem
Here is the catch in that 1970s engineering: a signed 32-bit integer maxes out at 2,147,483,647. Count seconds from the epoch and you hit that ceiling on 19 January 2038 at 03:14:07 UTC — one second later, the counter overflows to a negative number, which 32-bit systems interpret as 13 December 1901. Clocks would jump backwards 137 years.
The fix is the same one that solved it almost everywhere already: 64-bit time, which pushes overflow so far into the future (292 billion years) that it is effectively never. Modern operating systems, languages and databases made the switch years ago. The residual risk lives in old embedded systems, industrial controllers and unmaintained legacy code — the same long tail that made Y2K interesting. Auditing those is prudent; panic is not.
Leap seconds: the awkward exception
The Earth's rotation is irregular — it wobbles and gradually slows — so every so often, timekeepers insert a leap second (23:59:60 UTC) to keep atomic clocks aligned with the planet. Unix time's elegant model has no room for a 86,401-second day: by definition, every day is exactly 86,400 seconds.
Different systems paper over the crack differently. POSIX-style systems simply repeat the leap second, so two distinct UTC seconds share one Unix timestamp. Google famously “smears” the extra second across the whole day, slightly slowing its clocks so no second ever repeats. For everyday software the difference is invisible; for stock exchanges, GPS and scientific instruments, specialised time scales like TAI (which counts every real second, leaps included) do the precise work.
Frequently asked questions
How do I read a Unix timestamp?
Use a converter — many free ones live in your browser — or a one-liner: on Linux/macOS, `date -d @1700000000` prints the human date; in Python, `datetime.fromtimestamp(1700000000, tz=timezone.utc)`. The number counts seconds, so dividing roughly by 31.5 million gives years since 1970.
Is Unix time affected by time zones?
No. Unix time is defined in UTC and knows nothing of time zones or daylight saving — that is its whole point. A timestamp means the same instant in Tokyo and Toronto; only the displayed local time differs. Time-zone bugs happen in the conversion to local display, never in the stored number.
What actually happens in 2038?
On 19 January 2038, 32-bit signed counters hit their maximum and wrap to negative, which such systems would read as December 1901. In practice, nearly all modern operating systems, languages and databases moved to 64-bit time years ago. The remaining risk sits in old embedded devices and unmaintained legacy software — worth auditing, not panicking about.
How does Unix time handle leap seconds?
It does not count them at all. By definition, every UTC day is exactly 86,400 Unix seconds, so a leap second is effectively smeared or repeated depending on the system's chosen strategy (Google smears it across the day; POSIX systems repeat the second). For most applications the difference is invisible; for high-precision timing, specialised clocks like TAI are used instead.
Conclusion
Unix time endures because it solved the right problem: one number, one epoch, one time zone, no ambiguity. It quietly underpins file systems, databases, certificates and APIs — and it will keep doing so long past 2038 on 64-bit systems. The next time a timestamp looks like a random ten-digit number, you will know it is just the world's simplest clock, still ticking since the day Unix began.