Timestamp Converter — Unix Epoch to Date Online

A Unix timestamp counts seconds since the Unix epoch 1970-01-01T00:00:00Z UTC, per POSIX.1-2017 (IEEE Std 1003.1-2017) definition of `time_t`. JavaScript's `Date.now()` per ECMA-262 §21.4 returns milliseconds since that same epoch as an IEEE-754 double (so values around 1.7×10¹² for 2026 dates). Round-trip: `new Date(timestamp_ms).toISOString()` → ISO 8601-1:2019 string like `"2026-05-10T22:00:00.000Z"`; `new Date(iso_string).getTime()` → back to ms. The page auto-detects whether your input is seconds (10-digit values) or milliseconds (13-digit values) by magnitude, since the same number means different points in time depending on unit (1700000000 seconds = 2023; 1700000000 ms = 1970).

The Y2038 problem is the Unix timestamp wraparound: POSIX `time_t` as signed 32-bit integer wraps at 2³¹ − 1 = 2,147,483,647 seconds, corresponding to 03:14:07 UTC on Tuesday 19 January 2038. Past that, the counter overflows to negative, breaking date arithmetic and silently producing wrong results for any timestamp after that moment. Modern OS migrations to 64-bit `time_t`: Linux kernel 5.6 (March 2020); macOS 64-bit since 10.7 Lion (2011); Windows NT internally for decades. Vulnerable systems: embedded controllers (industrial, automotive, household appliances), legacy SCADA, 32-bit binaries on 64-bit OS, COBOL mainframe systems with 32-bit time fields, file formats like ext2/ext3 (ext4 has 64-bit), some database TIMESTAMP columns. JavaScript's IEEE-754 double range ±100,000,000 days from epoch covers up to year 275760, so browsers themselves are immune — but timestamps round-tripped through a 32-bit server side may corrupt.

Different systems use different time units in the same conceptual "Unix timestamp" field, and mixing them silently produces wrong dates. Seconds (Unix tradition, POSIX `time_t`, MySQL UNIX_TIMESTAMP(), Go's time.Unix()): 10-digit integers for current dates (1.7×10⁹). Milliseconds (JavaScript Date.now(), Java System.currentTimeMillis(), iOS NSDate timeIntervalSince1970 × 1000): 13-digit integers (1.7×10¹²). Microseconds (PostgreSQL TIMESTAMP internal storage, Python datetime.timestamp() × 10⁶): 16-digit integers (1.7×10¹⁵). Nanoseconds (Go time.Now().UnixNano(), Linux clock_gettime CLOCK_REALTIME): 19-digit integers (1.7×10¹⁸). The converter auto-detects by digit count: ≤10 digits → seconds; 11-13 → milliseconds; 14-16 → microseconds. A timestamp "1700000000" is the year 2023 if seconds, but 1970 if interpreted as milliseconds — silent off-by-1000 errors are a classic data-import bug.

Coordinated Universal Time (UTC) is currently 37 seconds behind International Atomic Time (TAI): TAI − UTC = +37 s, in effect since 1 January 2017 after the most recent leap second (31 December 2016 at 23:59:60 UTC). Per IERS Bulletin C (released January + July each year), 27 leap seconds have been inserted since the 1972 UTC redefinition + 10 initial offset = 37 total. Unix `time_t` does NOT count leap seconds — it pretends every day has exactly 86400 seconds, so a leap-second insertion creates a one-second ambiguity (timestamp 1483228800 corresponds to BOTH 2016-12-31T23:59:60Z and 2017-01-01T00:00:00Z in strict interpretation). Smear strategies handle this without breaking monotonicity: Google has been leap-smearing since 2008 (initially 20-hour cosine, now 24-hour linear noon-to-noon); Meta/Facebook 17-hour smear; Amazon AWS Time Sync 24-hour smear aligned with Google. Note Cloudflare's time.cloudflare.com applies the standard kernel correction at the appointed UTC instant — they do NOT smear. GPS time runs on TAI − 19 s and does NOT smear; high-precision financial sequencing and astronomy need TAI-aware tooling.

ISO 8601-1:2019 is the broad date-time standard with many optional fields; RFC 3339 (Klyne & Newman, IETF Standards Track, July 2002) is the strict subset for internet protocols requiring `YYYY-MM-DDTHH:MM:SS.ssssss±HH:MM` format with mandatory timezone offset (no naive datetime allowed). Naive datetime (no timezone info, e.g., Python `datetime(2026, 5, 10, 22, 0)`) is ambiguous — same string means different absolute moments in Tokyo vs New York. Timezone-aware datetime (`datetime(2026, 5, 10, 22, 0, tzinfo=ZoneInfo("Europe/Madrid"))`) is unambiguous. Database mapping: PostgreSQL TIMESTAMP WITHOUT TIME ZONE stores wall-clock; TIMESTAMP WITH TIME ZONE (timestamptz) stores UTC + converts on retrieval per session timezone. MySQL TIMESTAMP column auto-converts to/from UTC; DATETIME doesn't. Best practice for storage: UTC + offset (RFC 3339); for display: convert to user's timezone via IANA tz database lookup (see timezone-converter sister tool).