Convert epoch ↔ human date both ways. Auto-detects seconds vs milliseconds, shows local, UTC, ISO 8601 and relative time — with one-click copy.
🔒 Everything is computed locally in your browser.
Paste the epoch from a stack trace or DB row and instantly see when it happened in your time zone.
Pick a date and time, get seconds and milliseconds — ready for tokens, expiry fields and cron jobs.
A date in 1970 or the year 56,000? You mixed up seconds and milliseconds — the auto-detect flags it.
A Unix timestamp counts elapsed time from midnight UTC on 1 January 1970. Because it is a single number with no time zone attached, it is unambiguous — which is exactly why it is the right format for storing and transmitting instants, with conversion to local time left to the display layer.
The recurring practical problem is units. Unix tools, most databases and most backend languages use seconds; JavaScript's Date.now(), Java and many APIs use milliseconds. Mixing them silently produces dates that are wildly wrong — interpreting a millisecond value as seconds lands tens of thousands of years in the future, and the reverse lands in January 1970.
A quick sanity check: a current timestamp in seconds has 10 digits, and in milliseconds it has 13. Anything with 13 digits that appears to be in 1970 has been divided when it should not have been.
A signed 32-bit integer counting seconds overflows on 19 January 2038 at 03:14:07 UTC, wrapping to December 1901. This is the Year 2038 problem, and while 64-bit systems resolved it decades ahead of time, the issue is not fully closed.
It persists in embedded systems, older file formats, some database column types, and any code that stores a timestamp in a 32-bit field regardless of the platform's word size. It also arrives early wherever future dates are calculated: a 30-year mortgage schedule or a long-dated certificate computed today already crosses the boundary, which is why some systems began failing on this in the 2000s.
The related historical case is the Year 2000 problem, and the same lesson applies — the failure is in stored representations, not in the current clock. Checking column widths for anything holding a future date is a cheap precaution.
Unix time is deliberately not a true count of elapsed seconds. It assumes every day has exactly 86,400 seconds, which is not true when a leap second is inserted to keep clocks aligned with the Earth's rotation. During a leap second, Unix time either repeats a value or is smeared across a longer window, depending on the platform. The practical consequence is that a duration computed by subtracting two Unix timestamps can be off by a second across a leap event, and monotonically increasing time is not guaranteed.
ISO 8601 is the right interchange format when a human needs to read the value: 2026-08-04T14:30:00Z, where Z means UTC. Written this way, dates also sort correctly as plain strings, which is a genuinely useful property.
An offset is not a time zone, and conflating them causes real bugs. +01:00 records the offset at one instant; Europe/London is a rule set covering the whole history of that region's offsets, including daylight saving changes and past legislative shifts. Store the zone identifier if you need to compute future local times correctly — an event scheduled for 09:00 next October in London cannot be resolved from an offset alone.
It's in milliseconds but was read as seconds (or it's simply small). 13-digit numbers are milliseconds; divide by 1000 for seconds. The converter detects this automatically.
Systems storing seconds in signed 32-bit integers overflow on Jan 19, 2038. Modern 64-bit systems and JavaScript (which uses milliseconds in doubles) are unaffected.
Yes — paste anything like 2026-06-10T14:30:00Z and it converts the other way, too.
Signed 32-bit second counters overflow on 19 January 2038 and wrap to 1901. Modern platforms use 64-bit values, but 32-bit fields persist in embedded systems, file formats and database columns — and calculations involving future dates hit it early.