Unix Timestamps and Epoch Time Explained

A Unix timestamp is a single number representing a moment in time: the count of seconds that have elapsed since the Unix epoch, midnight UTC on January 1, 1970. It is the lingua franca of computer timekeeping because it reduces dates and times to one unambiguous integer with no time zone, no formatting, and no locale to argue about.

Why a Single Number?

Human date representations are riddled with ambiguity. Is 03/04/2026 March 4th or April 3rd? What time zone is 9:00 in? Storing time as seconds-since-epoch sidesteps all of it. Arithmetic becomes trivial: the duration between two events is simple subtraction, and sorting events chronologically is just sorting integers. Databases, log files, and APIs lean on this simplicity constantly.

0            → 1970-01-01 00:00:00 UTC  (the epoch)
1000000000   → 2001-09-09 01:46:40 UTC
1750000000   → 2025-06-15 ... UTC
86400        → one day worth of seconds

Seconds vs Milliseconds

A common source of off-by-1000 bugs is the unit. Classic Unix timestamps count seconds, and most command-line tools and databases use that. JavaScript's Date.now(), Java's System.currentTimeMillis(), and many web APIs count milliseconds since the epoch. If a timestamp looks like it lands in the year 55000, you are interpreting milliseconds as seconds; divide by 1000. A reliable heuristic: a current seconds timestamp has 10 digits, a milliseconds timestamp has 13.

Time Zones Are a Display Concern

The epoch is defined in UTC, so a Unix timestamp is inherently time-zone-free. The same integer represents the same instant everywhere on Earth. Time zones only enter the picture when you format that instant for a human. Timestamp 1750000000 might display as 09:00 in London and 18:00 in Tokyo, but it is one moment. Store and transmit timestamps in epoch or UTC; apply the user's time zone only at the presentation layer.

Leap Seconds and the Illusion of Linearity

Unix time pretends every day is exactly 86,400 seconds. Reality is messier: the Earth's rotation drifts, and occasional leap seconds are inserted into UTC to compensate. Unix time does not count leap seconds; instead, systems typically repeat or smear a second so the count stays aligned with civil time. For almost all applications this is invisible, but it means Unix time is not a perfectly continuous count of physical seconds since 1970.

The Year 2038 Problem

Systems that store the timestamp in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is reached at 03:14:07 UTC on January 19, 2038. One second later the counter overflows to a negative number, wrapping back to 1901. This is the 32-bit equivalent of the Y2K bug. Modern systems use 64-bit timestamps, which push the limit roughly 292 billion years into the future, but legacy embedded devices and old data formats remain at risk.