Unix Timestamp Converter
Convert Unix timestamps to human-readable dates and back — with a live epoch clock.
Current Unix Time
click to copy
Timestamp → Date
Enter a timestamp to convert it.
Date → Timestamp
Pick a date to get its timestamp.
Unix time is the number of seconds elapsed since midnight UTC on January 1st, 1970 — a single integer that has quietly become how almost every computer system on Earth represents time. Your phone, your database, your API responses, and the file you saved this morning all timestamp events this way. The elegance is that an integer has no time zones, no daylight saving, no calendar ambiguity: 1700000000 is the same instant everywhere on the planet. The complications live at the edges — milliseconds versus seconds, the 2038 problem, and leap seconds — and this converter handles the translation in both directions.
How the converter works
Paste a Unix timestamp to get the human-readable date in both UTC and your local time zone, or pick a date and time to get its timestamp. The converter detects whether your input is in seconds, milliseconds, microseconds, or nanoseconds by its magnitude — a common source of confusion, since different systems use different resolutions — and shows a live current-timestamp readout. Everything runs in your browser.
The formats
Seconds 1700000000 (10 digits, classic Unix)
Milliseconds 1700000000000 (13 digits, JavaScript)
Microseconds 1700000000000000 (16 digits, some databases)
Nanoseconds 1700000000000000000 (19 digits, Go, systems)
1700000000 = 2023-11-14 22:13:20 UTC
JS: Date.now() → milliseconds
Python: time.time() → seconds (float)
SQL: UNIX_TIMESTAMP(NOW()) → secondsThe seconds-versus-milliseconds confusion is the classic bug: feed a milliseconds value where seconds are expected and your date lands in the year 55,000; feed seconds where milliseconds are expected and you get January 1970. The digit count is the tell — ten digits is seconds until the year 2286, thirteen is milliseconds. Any timestamp that decodes to a date near 1970 or absurdly far in the future is almost certainly in the wrong unit, not wrong data.
What to know about Unix time
- 1Store timestamps in UTC, always, and convert to local time only for display. A Unix timestamp is inherently UTC — that is its entire value. The moment you store 'local time' you inherit time zones, DST transitions, and ambiguous hours. Every experienced backend developer has learned this once, expensively.
- 2The year 2038 problem is real but mostly solved. Signed 32-bit integers overflow on January 19, 2038, at 03:14:07 UTC — one second later, they wrap to 1901. Modern systems use 64-bit time, which is fine for 292 billion years, but embedded devices, old file formats, and legacy databases still carry the 32-bit assumption.
- 3Unix time ignores leap seconds by design. When a leap second is inserted, Unix time repeats a second rather than counting it, keeping every day exactly 86,400 seconds. This makes arithmetic clean and means Unix time is not technically a true count of elapsed physical seconds — a distinction that matters only in scientific and astronomical contexts.
- 4Negative timestamps are valid and mean before 1970. −86400 is December 31st, 1969. Systems that treat timestamps as unsigned, or as always-positive, silently corrupt historical dates — birthdays in the 1960s are the classic casualty in poorly built forms.
- 5Beware timestamp comparisons across resolutions. A database storing seconds compared against an API returning milliseconds makes every event appear to be either in 1970 or far future depending on direction. When timestamps disagree wildly, check units before checking data.
Frequently asked questions
Why January 1st, 1970?
It is essentially arbitrary — a convenient round date chosen by Unix's developers at Bell Labs in the early 1970s, recent enough to keep numbers small on the hardware of the day. Earlier Unix versions actually used different epochs and units before settling on seconds-since-1970. It has no astronomical or historical significance; it simply needed to be some fixed point, and it stuck.
How do I know if a timestamp is seconds or milliseconds?
Count digits. Current Unix time in seconds is ten digits (and stays ten until 2286); milliseconds is thirteen; microseconds sixteen; nanoseconds nineteen. This converter auto-detects by magnitude. The symptom of getting it wrong is unmistakable: a date in 1970 means you treated milliseconds as seconds' bigger sibling wrongly, and a date tens of thousands of years out means the reverse.
What is the year 2038 problem?
Classic Unix stored time as a signed 32-bit integer, which reaches its maximum — 2,147,483,647 — on January 19, 2038, at 03:14:07 UTC. One second later it overflows to a negative number, which decodes as December 1901. Modern 64-bit systems are unaffected, but embedded controllers, old formats, and legacy code still hold 32-bit assumptions, making it a slow-motion, mostly-managed successor to Y2K.
Does Unix time handle time zones?
By not having them, which is the right answer. A Unix timestamp identifies an instant, not a wall-clock reading — 1700000000 is the same moment in Tokyo and Toronto; only its human rendering differs. Time zones enter exclusively at display time, when the timestamp is formatted for a viewer. This is why storing timestamps and displaying dates are, and should remain, separate operations.
What about leap seconds?
Unix time pretends they do not exist. When a leap second is added to the civil calendar, Unix time either repeats one second or smears it across nearby hours, depending on the system — keeping every day exactly 86,400 Unix seconds. The trade is deliberate: arithmetic stays trivially simple, at the cost of not being a perfectly faithful count of physical seconds. For virtually all computing purposes, the trade is worth it.