What is Unix Time?

What is Unix Time?

Unix time (also called Unix timestamp, POSIX time, or Epoch time) is a standardized way of representing a point in time as a single integer — the number of seconds that have elapsed since January 1, 1970, at exactly 00:00:00 Coordinated Universal Time (UTC).

This reference moment is called the Unix Epoch. Moments before the Epoch are represented as negative numbers; moments after are positive.

For example, the timestamp 1700000000 corresponds to November 14, 2023 at 22:13:20 UTC.

History

Unix time originated in the late 1960s and early 1970s at Bell Labs, where Ken Thompson and Dennis Ritchie were developing the Unix operating system. The original timestamp was stored as a 32-bit integer measuring 1/60th-second intervals, but this was quickly revised to full seconds.

The choice of 1970-01-01 as the epoch was practical rather than symbolic — it was close to when the system was being developed, and using it meant the immediate future could be represented with small positive integers. Several other epochs have been used in computing history (Apple's classic Mac OS used January 1, 1904; Windows FILETIME uses January 1, 1601), but the Unix epoch became the universal standard.

How It Works

Converting a Unix timestamp to a human date is arithmetic: add the timestamp as seconds to the epoch date (1970-01-01 00:00:00 UTC). Modern programming languages do this automatically via their date/time libraries.

Unix timestamps are often stored in different precisions depending on the use case:

• Seconds (10 digits as of 2001) — the standard; e.g., 1700000000
• Milliseconds (13 digits) — JavaScript's Date.now() returns this
• Microseconds (16 digits) — used in databases like PostgreSQL
• Nanoseconds (19 digits) — used in high-performance systems

Our converter automatically detects the unit by digit count.

Unix Time and Timezones

One of Unix time's key properties is that it is timezone-independent. A Unix timestamp always refers to a specific moment in UTC. Converting it to a local time requires knowing the UTC offset for that timezone at that moment (since offsets change with DST).

This is why storing dates as Unix timestamps is strongly recommended in databases and APIs: you avoid ambiguity about what timezone was intended, and DST transitions cannot corrupt stored values. Display conversion to local time happens only at the presentation layer.

Use our Timezone Converter to see a timestamp in multiple timezones simultaneously.

The Year 2038 Problem

Many legacy systems store Unix time as a 32-bit signed integer. The maximum value of a 32-bit signed integer is 2,147,483,647, which corresponds to January 19, 2038, at 03:14:07 UTC.

On that date, one second later, the value will overflow and wrap around to −2,147,483,648, which represents December 13, 1901. This is analogous to the Y2K bug and could cause system crashes, incorrect date calculations, and security vulnerabilities in affected systems.

The fix is straightforward: use a 64-bit integer instead. A signed 64-bit Unix timestamp can represent dates up to approximately 292 billion years in the future. Most modern operating systems, programming languages, and databases already use 64-bit timestamps. The concern is primarily with embedded systems, old databases, and legacy software.

Common Uses

• Databases — Storing created_at, updated_at, and event timestamps
• HTTP headers — Cache-Control, Last-Modified, and Expires headers use GMT dates derived from timestamps
• JWT tokens — The iat (issued at) and exp (expiry) claims are Unix timestamps
• Log files — System logs often record events as Unix timestamps for easy sorting and querying
• Git — Commit timestamps are stored as Unix timestamps internally
• APIs — REST and GraphQL APIs often return timestamps as integers to avoid timezone confusion
• File systems — File modification times (mtime, ctime, atime) are Unix timestamps

Frequently Asked Questions