The current Unix time and conversion between timestamp and date.
A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC. This date is known as the "Unix Epoch." Unix timestamps are used as the standard time format in virtually all operating systems, databases, and programming languages.
The classic Unix timestamp counts in seconds (10 digits, e.g. 1700000000). However, many modern systems like JavaScript (Date.now()) use milliseconds (13 digits, e.g. 1700000000000). This tool automatically detects whether a value is given in seconds or milliseconds.
On January 19, 2038 at 03:14:07 UTC, a 32-bit Unix timestamp will reach its maximum value (2147483647). Systems still using 32-bit integers for timestamps will experience an overflow. Modern 64-bit systems are not affected.
0 — January 1, 1970 00:00:00 UTC (Unix Epoch)1000000000 — September 9, 2001 01:46:40 UTC1700000000 — November 14, 2023 22:13:20 UTC2000000000 — May 18, 2033 03:33:20 UTC2147483647 — January 19, 2038 03:14:07 UTC (32-bit max)These timestamps show up often in search queries, API responses, and database exports — jump straight to a detail page with local time, ISO 8601 and other formats:
1764244800 — 2025-11-27 12:00:00 UTC
1764432000 — 2025-11-29 16:00:00 UTC
1768175999 — 2026-01-11 23:59:59 UTC
When Ken Thompson and Dennis Ritchie began writing Unix in 1969, they needed a simple, monotonically increasing count of seconds. They picked 1 January 1970, 00:00:00 UTC as the zero point — the famous "Unix epoch". The convention outlived every architecture, every Linux distribution, every database engine, every programming language: Java System.currentTimeMillis(), PostgreSQL epoch, Excel's UNIX_TIMESTAMP(), JavaScript Date.now() — all point to the same anchor. POSIX standardised the type as time_t in IEEE Std 1003.1. The charm: a Unix timestamp is language- and time-zone-independent. A single integer like 1718000000 describes an exact moment on Earth, whether read in Tokyo, Berlin, or Lima.
The most important everyday distinction is seconds vs. milliseconds. Classic Unix counts in seconds (10-digit number like 1718000000), JavaScript and Java in milliseconds (13-digit number like 1718000000000). Microseconds and nanoseconds appear in databases (PostgreSQL TIMESTAMP, Linux clock_gettime) as well as in high-frequency trading and tracing systems. This tool auto-detects 13-digit inputs as milliseconds and divides by 1000. When you correlate logs from different systems, be aware of the resolution — otherwise an entry will appear to live in the year 56,088 instead of 2024.
A subtle peculiarity: Unix time ignores leap seconds. While the International Earth Rotation Service (IERS) inserts a leap second into UTC when needed — most recently on 31 December 2016 — the Unix second counter remains continuous. In practice, time_t treats every day as if it were exactly 86,400 seconds long. For applications that need astronomically correct UT1 time (satellite navigation, astronomy) Unix time is not enough — there you need TAI or GPS time. For 99.99% of web developers, accountants, and data analysts that is irrelevant.
From an ISO date to a Unix second: unix = (UTC-milliseconds since 1970-01-01) / 1000. In most languages: Date.UTC(year, month-1, day, hour, min, sec) / 1000 (JavaScript), mktime() or strtotime() (PHP), datetime.timestamp() (Python). Inverse: date = new Date(unix * 1000) or date('Y-m-d H:i:s', $unix). Each day adds 86,400 seconds, each hour 3,600. Coming from Excel: excel_serial × 86,400 − 2,209,161,600 = unix seconds (Mac convention) and similar for Windows. For ISO 8601 strings, JavaScript uses Date.parse('2024-06-09T12:00:00Z') and returns milliseconds.
A handful of anchor timestamps for quick orientation:
1738200000 = 2025-01-30 04:00:00 UTC (Thursday) — equals 05:00 Berlin (CET).1893456000 = 2030-01-01 00:00:00 UTC — popular long-term cache header value.2147483647 = 2038-01-19 03:14:07 UTC — exact upper bound for 32-bit signed time_t (Y2038 problem).0 = 1970-01-01 00:00:00 UTC (Thursday) — the origin; negative values are allowed and represent earlier dates.1717891200000 (13 digits, ms) = 2024-06-09 00:00:00 UTC — typical JavaScript output from Date.UTC(2024,5,9).Three issues come up again and again. The most famous is the Y2038 problem: a 32-bit signed time_t overflows on 2038-01-19 03:14:08 UTC and wraps to a negative number — old embedded systems (routers, industrial PCs, in-car computers) may hang. Linux kernel ≥ 5.6 uses 64-bit time_t even on 32-bit platforms; PHP 8 and Node.js already use 64-bit integers/doubles. Second: DST is not encoded in Unix time. When displaying, the receiver must apply the local zone — the IANA database (tzdata) provides the rules per region, including historic DST changes. Third, the seconds-vs-milliseconds trap: accidentally feeding 1718000000000 as seconds drops you in the year 56,088. Rule of thumb: a 10-digit number today is seconds, a 13-digit number is milliseconds.
-1 equals 1969-12-31 23:59:59 UTC. Negative values are permitted by POSIX but are poorly supported by some systems (e.g. Windows MFC time functions).time() returns seconds, JavaScript Date.now() returns milliseconds — factor 1000. Also, PHP uses the time zone from date_default_timezone_set or php.ini, JavaScript uses the browser's zone — if you compare strtotime('today') with JavaScript midnight, you can drift by a few hours.