What Is a Unix Timestamp?

What is a Unix timestamp?

A Unix timestamp (also called epoch time or POSIX time) is a single number: the count of seconds elapsed since the Unix epoch — 1 January 1970 at 00:00:00 UTC. For example, 1767225600 is 1 January 2026 at 00:00:00 UTC, and 1000000000 fell on 9 September 2001. Dates before 1970 are simply negative: -1 is 31 December 1969 at 23:59:59 UTC.

Why 1970? The first Unix systems were built at Bell Labs around 1969–1971, and their engineers needed a "time zero" for the system clock. The earliest epoch was actually 1971; within a few years it was redefined as 1 January 1970 — a recent, round date that kept the counter small — and the convention stuck. POSIX later standardized it, and today virtually every operating system, database, log file and API speaks epoch time.

Timestamps have no timezone

A timestamp describes an absolute instant, not a wall-clock reading. The value 1767225600 is the same moment everywhere on Earth: it is midnight in London, 08:00 in Beijing and 19:00 the previous evening in New York. Timezones only enter the picture when a human reads the date. That is why the standard advice is to store and transmit timestamps (which are inherently UTC-based) and convert to local time only for display.

Seconds, milliseconds and microseconds

Classic Unix time counts whole seconds, but many systems need finer resolution and multiply up. The same instant looks different depending on the unit:

JavaScript's Date.now() returns milliseconds, as does Java's System.currentTimeMillis(), while C, PHP and Go are rooted in seconds. Mixing the units is the most common epoch bug: a millisecond value read as seconds points roughly 56,000 years in the future, while a seconds value read as milliseconds lands back in January 1970.

The quick sanity check is digit count. Until the year 2286, a current timestamp in seconds has 10 digits (around 1.7 to 9.9 billion); the same instant in milliseconds has 13, and in microseconds 16. Good converters apply this heuristic automatically — treating any value of 12 digits or more as milliseconds — so pasting either form just works.

Leap seconds and the Year 2038 problem

Leap seconds are not counted

Unix time assumes every day has exactly 86,400 seconds. Real UTC does not: since 1972, 27 leap seconds have been inserted to keep atomic time aligned with Earth's slowing rotation. Timestamps ignore them, so a Unix clock briefly repeats a second (or is "smeared" across the day, as some providers do) when one occurs. The practical impact is small — a duration measured across a leap second can be off by about a second — and leap seconds are being phased out by 2035.

The Year 2038 problem

Many older programs store the timestamp in a signed 32-bit integer, which maxes out at 2147483647 — 19 January 2038 at 03:14:07 UTC. One second later the value overflows to -2147483648, which those systems read as 13 December 1901. Embedded devices, legacy databases and old file formats are the main risk. Systems using a 64-bit time_t are safe for roughly the next 292 billion years.

Get the current timestamp in code

Every mainstream language exposes epoch time in one call:

Each line returns whole seconds. JavaScript and Java natively work in milliseconds, which is why the division by 1,000 (or a seconds-specific method) is needed; Python and Go also offer time.time_ns() and time.Now().UnixMilli() when you need finer units.

Try it: paste any timestamp — for example 1767225600 or its millisecond form 1767225600000 — into the Unix Timestamp Converter to see the matching date in UTC, your local time, ISO 8601 and relative time, with seconds and milliseconds detected automatically. It also works in reverse: pick a date and time to get the corresponding timestamp.