Epoch Converter

Paste a Unix timestamp (seconds or milliseconds since 1970-01-01 UTC) and the converter returns the human-readable date in your local timezone, UTC, and ISO 8601 format. Or go the other way — type a date and get the epoch back.

Millisecond timestamps are the modern default in JavaScript, Java, and most APIs (1234567890123). Second timestamps are the Unix tradition (1234567890). The converter detects the unit from the magnitude — anything past 13 digits is milliseconds; 10 digits is seconds — but you can override if your data is unusual.

Note the year-2038 problem. 32-bit signed integer Unix timestamps overflow on January 19, 2038. Modern systems use 64-bit timestamps that won't overflow for ~292 billion years, but legacy embedded systems and old database columns are still vulnerable.

What the timestamp actually represents: seconds (or sub-second units) elapsed since the Unix epoch — 1970-01-01 00:00:00 UTC. Always UTC by definition, no timezone offset embedded. The conversion to a human-readable date applies a timezone (your browser's local zone by default, with UTC and ISO 8601 always shown alongside). The format string variations matter: ISO 8601 (2024-04-15T13:30:00Z) is the unambiguous machine format; locale strings (4/15/2024, 1:30 PM) are ambiguous because '4/15' and '15/4' read differently in US vs European locales.

Worked example: timestamp 1700000000. The converter detects 10 digits → seconds. Output: November 14, 2023 22:13:20 UTC, which is 17:13:20 EST on November 14 if you're in the US Eastern timezone. ISO 8601: 2023-11-14T22:13:20Z. Now paste 1700000000000 (13 digits). Same moment, just expressed in milliseconds — the conversion divides by 1000 internally and lands on the same date. Now go reverse: paste '2024-12-25T00:00:00Z'. Output: 1735084800 (seconds), 1735084800000 (milliseconds). Useful for plugging into APIs that take epoch parameters.

Where timestamps surprise you: leap seconds. Unix time pretends they don't exist — every Unix day is exactly 86,400 seconds, even though some real days have 86,401 because of an inserted leap second. The result: Unix time is roughly synchronized with UTC but can drift by a few seconds across leap second insertions. For most uses this is invisible. For high-precision astronomical or telecommunication uses, it matters and you need TAI (International Atomic Time) instead. Also: the year-2038 problem. 32-bit signed integers max out at 2,147,483,647 seconds, which is January 19, 2038 03:14:07 UTC. After that they wrap to negative numbers and software does wrong things with dates. Modern systems use 64-bit timestamps; legacy databases and embedded firmware can still bite. Audit your old systems before 2038 sneaks up.