What is a Unix timestamp? Epoch, UTC, and ISO 8601

What a Unix timestamp is

A Unix timestamp is a count of seconds since the Unix epoch — 00:00:00 UTC on 1 January 1970. Timestamp 0 is the epoch itself, and 1700000000 is 2023-11-14 22:13:20 UTC. It is a single number that names an exact instant, with no time zone and no calendar attached, which is why databases, log files, and APIs use it to store time unambiguously.

The same idea goes by several names. Epoch time and POSIX time mean the same thing, because the POSIX standard defines "seconds since the Epoch" this way. Linux timestamp usually means the same number too — it is not specific to Linux. Sorting timestamps numerically sorts the instants chronologically, and subtracting two of them gives the gap in seconds, which is why they are convenient to compute with.

Seconds, milliseconds, microseconds, and nanoseconds

Not every system counts in seconds. JavaScript's Date.now() returns milliseconds, many databases store microseconds, and Go and Rust often use nanoseconds. The value is the same instant each time, just scaled, so the quickest way to tell them apart is to count the digits.

Mixing them up is the single most common timestamp bug. A milliseconds value read as seconds lands in the year 55840 — tens of thousands of years in the future — and a seconds value read as milliseconds lands a few weeks after the epoch, in January 1970.

Why Unix time ignores leap seconds

A Unix timestamp is not quite the number of seconds that have actually elapsed since 1970. UTC is kept in step with the Earth's rotation by occasionally inserting a leap second, and 27 of them have been added since 1972 — which is why atomic time (TAI) now runs 37 seconds ahead of UTC.

POSIX defines seconds since the Epoch with a formula based on the calendar date, and that formula has no room for a 61st second in a minute. So a leap second does not advance Unix time: systems typically repeat or smear the same timestamp across it. The practical consequences are small but real — a one-second gap can appear between a timestamp difference and true elapsed time, and a repeated timestamp can break code that assumes they are unique. For measuring a duration inside a program, use a monotonic clock rather than a timestamp difference. The General Conference on Weights and Measures voted in 2022 to stop adding leap seconds by 2035.

Timestamps and time zones

A Unix timestamp always refers to an instant in UTC. A time zone only changes how that instant is written as a local clock time. The timestamp 1700000000 is a single moment that reads as 22:13:20 in London, 17:13:20 the same day in New York, and 07:13:20 the next morning in Tokyo — the same instant, three different wall clocks.

This is why a timestamp is not "a UTC time" in the sense of a formatted string: it carries no offset because it needs none. Storing timestamps rather than local date-and-time text avoids a whole category of bugs around daylight saving, ambiguous local times, and zone databases changing. Convert the timestamp to a local time only when you display it.

ISO 8601 and RFC 3339

ISO 8601 is the standard text format for dates and times, such as 2023-11-14T22:13:20Z. The trailing Z means UTC. RFC 3339 is the stricter internet profile of ISO 8601 that most APIs actually follow, and the two agree for everyday timestamps.

A time in another zone carries an explicit offset instead of Z: the instant above is 2023-11-15T03:43:20+05:30 in India. Because the fields run from largest to smallest and are zero-padded, ISO strings in the same offset sort correctly as plain text. Email and HTTP use a different format again, RFC 5322, which writes the same instant as Tue, 14 Nov 2023 22:13:20 GMT. The Timestamp Converter reads all of these — and dates with the month in words — and shows the numeric timestamp beside each one.

Dates before 1970

Timestamps can be negative. A negative value counts seconds backwards from the epoch, so -1 is 1969-12-31 23:59:59 UTC. This is how systems represent historical dates, and it is well supported, but it is a common source of bugs in code that assumes a timestamp is a positive number — validation that rejects a leading minus sign, or an unsigned database column that cannot store one.

The Year 2038 problem

A signed 32-bit integer can hold a Unix timestamp only up to 2147483647, which is 03:14:07 UTC on 19 January 2038. One second later the value overflows to the most negative 32-bit number, and the date reads as 13 December 1901. That is the Year 2038 problem, and it is the modern counterpart of Y2K.

An unsigned 32-bit integer avoids the 1901 wrap and runs to 06:28:15 UTC on 7 February 2106, but it cannot hold dates before 1970 at all. A signed 64-bit integer — now the default on current operating systems, language runtimes, and databases — pushes the limit roughly 292 billion years out, which ends the problem for practical purposes.

The risk today sits in older embedded devices, long-lived file and network formats that pin the field at 32 bits, and database columns typed as a 32-bit integer. Check the width of the column or struct field that stores the time rather than the platform, since a 64-bit system can still write a 32-bit timestamp. The converter's 32-bit limit quick value jumps straight to the 2038 boundary so you can see how a system behaves either side of it.

Frequently asked questions