What Is Unix Time?
Updated 12 August 2026
A plain-English guide to Unix time (Epoch time) — why it counts seconds from 1 January 1970, how it avoids timezone bugs, the Year 2038 problem, and how to convert it yourself.
The basics
Unix time — also called Epoch time or POSIX time — is a way of representing a specific moment as a single number: the count of seconds elapsed since 00:00:00 UTC on 1 January 1970, known as "the Epoch". No months, days, or timezones — just one integer.
That simplicity is exactly why it is everywhere in software: it is trivial to store, compare, sort, and do arithmetic on, without any of the calendar or timezone edge cases that come with human-readable dates.
Why not just store a date?
Human-readable dates carry a lot of baggage: timezones, daylight saving transitions, locale-specific formats (is 03/04/2026 the 3rd of April or the 4th of March?), and leap years. Comparing two dates stored as strings, or across two servers in different timezones, is a common source of bugs.
A Unix timestamp sidesteps all of that. It always refers to the same instant regardless of where in the world it is read, and comparing two timestamps is just comparing two numbers — no parsing, no timezone conversion, no ambiguity.
Seconds vs milliseconds
The original Unix standard counts in seconds, and most backend languages, databases, and the HTTP protocol itself follow that convention. JavaScript is the notable exception — Date.now() and many web APIs return milliseconds since the Epoch instead.
A quick way to tell them apart: a current seconds-based timestamp is 10 digits long; a current milliseconds-based one is 13 digits. Mixing the two up — feeding a seconds value into code expecting milliseconds — is a very common bug, and usually produces a date sometime in 1970.
The Year 2038 problem
Many older systems store Unix time as a signed 32-bit integer, which can only count up to 2,147,483,647 seconds past the Epoch. That number is reached at 03:14:07 UTC on 19 January 2038 — after which the value overflows and wraps around to a large negative number, which computers interpret as a date in December 1901.
Modern 64-bit systems avoid this entirely — a 64-bit signed integer can represent Unix time for roughly 292 billion years into the future — but embedded systems, older databases, and legacy 32-bit software can still be affected, in the same way the "Y2K" date bug affected two-digit years.
Where you'll run into it
- JWT tokens — the
iat(issued at) andexp(expiry) claims are both Unix timestamps in seconds. - Databases — many store creation/update timestamps as Unix time for fast indexing and comparison.
- APIs — REST and log timestamps are frequently returned as Unix time to avoid timezone ambiguity across clients.
- Cron and scheduling systems — internally track "next run" as a Unix timestamp before converting to a human-readable time.