Unix Timestamp Today
The current Unix timestamp — seconds elapsed since 1 January 1970 at 00:00:00 UTC. Updated live, to the second.
Any date → Unix timestamp
Pick any date to see its Unix timestamp (midnight local time).
What is a Unix timestamp?
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 1 January 1970 at 00:00:00 UTC. It's the universal time format used by almost every programming language and operating system on Earth.
Because it's a single monotonic integer with no timezone information, it's unambiguous across systems — perfect for timestamps in databases, log files, APIs, and network protocols.
Seconds vs milliseconds
Unix timestamps come in two common flavors:
- Seconds — the classic POSIX value. Currently a 10-digit number like
1745456400. - Milliseconds — used by JavaScript's
Date.now()and many modern APIs. 13 digits like1745456400000.
The Year 2038 Problem
Unix timestamps are traditionally stored as signed 32-bit integers. The maximum value, 2,147,483,647, will be reached at 03:14:07 UTC on 19 January 2038. Systems still using 32-bit timestamps will overflow and wrap to a negative number, potentially producing December 13, 1901.
Most modern systems have already migrated to 64-bit timestamps, which won't overflow for another 292 billion years.
Converting timestamps to readable dates
Every Unix timestamp corresponds to exactly one moment in UTC. Converting to local time is a matter of adding the timezone offset. ISO 8601 ("2026-04-23T09:31:00Z") is the standard human-readable format derived from a timestamp.
Why Unix time exists
Before Unix timestamps, every operating system represented dates differently. UNIX, developed at Bell Labs in the 1970s, made a deliberate simplification: every moment is just a big integer, counting seconds since 1 January 1970. This decision has propagated to essentially every modern computing system:
- Linux, macOS, and Windows all use Unix time internally for file timestamps.
- JavaScript's
Date.now()returns Unix time in milliseconds. - MySQL and PostgreSQL store timestamps internally as 64-bit Unix times.
- HTTP cookies, JSON Web Tokens, Git commits, and blockchain transactions all use Unix timestamps.
The Year 2038 Problem
The most famous risk in Unix time is the 2038 rollover. Traditional 32-bit signed integers can store values up to 2,147,483,647. That's a lot — but it's exactly the number of seconds from 1 January 1970 to 03:14:07 UTC on Tuesday, 19 January 2038.
At that moment, systems still using 32-bit Unix time will overflow. The timestamp will wrap around to −2,147,483,648, which represents 13 December 1901. Systems doing date math could produce nonsensical results — expired certificates becoming valid, transactions dated to the Victorian era, backup systems deleting records they think are 137 years old.
Fortunately, most modern systems have already migrated to 64-bit integers, which can store Unix times for the next 292 billion years. Embedded systems, legacy databases, and some industrial control systems remain at risk and are being progressively upgraded.
Unix time quirks worth knowing
- Leap seconds are ignored. POSIX pretends every day has exactly 86,400 seconds. When a real leap second occurs (like 31 December 2016), Unix time either repeats a second or stretches one — depending on implementation.
- No timezone. Unix time is always UTC. Converting to local time requires knowing the observer's timezone separately.
- Negative values are valid. Unix time −86,400 is 31 December 1969 at 00:00:00 UTC. Dates before 1970 are expressed as negative numbers.
Famous Unix timestamps
- 0 — 1 January 1970 00:00:00 UTC (the epoch)
- 1,000,000,000 — 9 September 2001 at 01:46:40 UTC (celebrated as "billennium" by the Unix community)
- 1,234,567,890 — 13 February 2009 at 23:31:30 UTC
- 2,000,000,000 — 18 May 2033 at 03:33:20 UTC
- 2,147,483,647 — 19 January 2038 at 03:14:07 UTC (32-bit signed maximum)