offlineutils
Glossary
Plain English
Cross-linked to tools

Unix Timestamp

Also known as: Unix time, epoch time, POSIX time, epoch seconds, time_t

A Unix timestamp is a single number counting the seconds elapsed since 1970-01-01T00:00:00Z, ignoring leap seconds — a time zone-free, language-agnostic way to name an exact instant, which is why it is what logs, databases, and APIs store internally.

Overview

The appeal is that it is just an integer. There is no time zone to misread, no ambiguity about whether 03/08 means March or August, and comparing two instants is plain arithmetic. That epoch — midnight UTC on 1 January 1970 — was chosen for early Unix simply because it was conveniently close to the era the systems ran in, and it stuck.

The first thing to know is that a Unix timestamp is not a true count of elapsed seconds. POSIX defines it with a formula that assumes every day contains exactly 86,400 seconds, so the 27 leap seconds inserted into UTC between 1972 and 2016 do not exist as far as Unix time is concerned. Two timestamps 86,400 apart are always the same wall-clock time the next day, which is what calendar code wants, but the interval between them is not necessarily 86,400 SI seconds. If you need genuinely monotonic elapsed time, use a monotonic clock, not wall-clock epoch differences.

The second is units. Classical Unix time is seconds, but nothing labels the number, so the same instant appears with three, six, or nine extra digits depending on where it came from: milliseconds in JavaScript and Java, microseconds in Cassandra write times, nanoseconds in Go, OpenTelemetry, and InfluxDB. Digit count is the practical tell — around 10 digits is seconds, 13 milliseconds, 16 microseconds, 19 nanoseconds — and misreading it by a factor of 1,000 is the single most common epoch bug, producing a date in 1970 or somewhere around the year 56,000.

The third is the ceiling. A signed 32-bit time_t cannot exceed 2,147,483,647, so it runs out at 03:14:07 UTC on 19 January 2038 and wraps to 1901 — the Year 2038 problem, still live in embedded systems, old file formats, and any database column typed as a 32-bit int. Nanosecond timestamps have their own quieter ceiling: 19 digits exceeds what a 64-bit float can represent exactly, so any code that passes one through a JavaScript number loses the last few digits before it even starts converting.

Common questions about Unix Timestamp

Is a Unix timestamp always in seconds?
No, and nothing in the value tells you which unit it is — you have to infer it from the digit count. Roughly 10 digits is seconds, 13 is milliseconds, 16 is microseconds, and 19 is nanoseconds. JavaScript's Date.now() returns milliseconds while most Unix tooling and C's time() return seconds, which is why a value being off by a factor of 1,000 is such a common bug.
Does Unix time account for leap seconds?
No. POSIX computes it as if every day were exactly 86,400 seconds long, so the 27 leap seconds added to UTC since 1972 are simply absent. That keeps calendar arithmetic simple but means the difference between two timestamps is not a precise count of elapsed SI seconds. Some infrastructure sidesteps the discontinuity by 'smearing' a leap second across several hours instead of repeating a value.
Can a Unix timestamp be negative?
Yes. Negative values are instants before 1970 — -86400 is 1 January 1969. Plenty of software gets this wrong, either rejecting negatives outright or truncating toward zero instead of flooring, which lands sub-second values on the wrong side of the epoch.
What is the Year 2038 problem?
A signed 32-bit integer maxes out at 2,147,483,647, which as Unix time is 03:14:07 UTC on 19 January 2038. One second later it overflows to negative and affected software reads the date as December 1901. Modern 64-bit systems are fine — the exposure is in embedded devices, binary file formats, and database columns still typed as 32-bit ints.
Why do systems store Unix time instead of a formatted date?
Because it removes every ambiguity that formatted dates introduce: no time zone, no daylight saving, no locale-dependent day/month order, no parsing. It is compact to store, trivial to index and sort, and unambiguous across languages. Formatting into a local wall-clock time is a presentation concern, done as late as possible.

Tools that work with Unix Timestamp

Timestamp Converter

Convert Unix time in any unit — seconds to nanoseconds — with exact precision.

Cron Expression Explainer

Translate cron expressions into plain English and preview the next runs.

ULID Generator

Generate time-ordered, URL-safe ULIDs in bulk.

Related concepts

External references