Unix Timestamp Converter
Convert between Unix epoch seconds (or milliseconds) and human-readable dates. Live clock, multiple output formats, timezone-aware.
Text & dev tools
Updates every second. Click either value to copy.
Paste any epoch number — 10 digits = seconds, 13 digits = milliseconds. We auto-detect.
10-digit epoch = seconds since 1970-01-01 UTC (most APIs, JavaScript
Math.floor(Date.now()/1000))13-digit epoch = milliseconds (JavaScript
Date.now(), Java System.currentTimeMillis())Negative epoch = dates before 1970 (rare, used in some scientific contexts).
Enter a value and click Convert.
Unix time, briefly
Unix time (also called POSIX time or epoch time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1971 — except without leap seconds. It's the lingua franca of timestamps in computing because it's timezone-independent (always UTC), easy to sort, and trivially easy to do math on (just add/subtract seconds).
Most systems today use either 10-digit (seconds) or 13-digit (milliseconds) Unix timestamps. JavaScript's Date.now() returns milliseconds; Python's time.time() returns seconds (as a float); Unix date +%s returns integer seconds.
- Always UTC — Unix timestamps have no concept of timezone. The same moment in time produces the same epoch everywhere on Earth.
- Y2K38 problem — 32-bit Unix time overflows on 2038-01-19 03:14:07 UTC. Most 64-bit systems are unaffected, but legacy embedded systems may need patching.
- No leap seconds — every day is treated as exactly 86400 seconds. Real UTC days with leap seconds (which have happened 27 times since 1972) are papered over by the OS.
- Sortable as numbers — earlier timestamps sort before later ones, which makes epoch ideal for database indexes.
Timestamp Converter — FAQ
How do I detect whether a number is seconds or milliseconds?
The rule of thumb: 10-digit numbers (1,000,000,000+) are seconds; 13-digit numbers (1,000,000,000,000+) are milliseconds. The crossover from seconds to ms happens around 2001-09-09 (when epoch seconds hit 10 digits). This converter auto-detects based on the magnitude — if the value is > 10^12 we treat it as ms, otherwise as seconds.
Why does the same epoch give different human times on different machines?
It doesn't — Unix epoch is always UTC. But when you display it as a human-readable string, you have to pick a timezone. Most JS methods like new Date(0).toString() use the browser's local timezone, which is why you might see "1969-12-31 19:00:00 EST" on a US machine and "1970-01-01 05:30:00 IST" on an Indian one for the same epoch=0. This converter lets you choose the display timezone explicitly.
What's the difference between ISO 8601 and RFC 2822?
ISO 8601 (2024-03-15T14:30:00Z) is the modern standard — unambiguous, machine-parseable, sortable as a string, and used by every modern API. RFC 2822 (Thu, 14 Mar 2024 14:30:00 +0000) is older, used in email headers and HTTP/1.1 dates. Use ISO 8601 for anything new.
How accurate is the "X minutes ago" relative format?
It's exact to the second, but the human-friendly rounding follows common conventions: under 60s = "just now", 60s-60m = "X min ago", 60m-24h = "X hr ago", 24h-7d = "X days ago", 7d+ switches to absolute date. Useful for social-media-style timestamps.
Can this converter handle pre-1970 dates (negative epoch)?
Yes — JavaScript Date supports negative epoch values. Entering -1 gives you 1969-12-31 23:59:59 UTC. This is occasionally used in scientific and historical databases, though most apps stick with positive epoch.