Unix Timestamp Converter
Live epoch clock, timestamp-to-date, and date-to-timestamp — auto-detects seconds, milliseconds, or microseconds.
Reading Unix time without doing the math yourself
A Unix (epoch) timestamp is just a count of seconds since January 1, 1970, 00:00:00 UTC — the format nearly every programming language, database, log file, and API uses internally because it's a single portable number instead of a locale-dependent string. The catch is that the same tool is asked to handle several flavors of that number: whole seconds, JavaScript-style milliseconds, and the microsecond or nanosecond values some databases emit, plus timestamps that predate 1970 and show up negative. This page reads whichever one you paste, tells you which unit it assumed, and shows the result as a local date, a UTC date, ISO 8601, and a plain-English relative phrase — while the panel below it does the reverse conversion and a ticking clock keeps the current epoch value visible the whole time.
Worked examples
Reading a timestamp out of a server access log
A log line records the request time as a bare integer. Pasting it in shows exactly when the request happened, in both UTC and the reader's own time zone.
- Input
- 1700000000
- Detected
- Seconds (10 digits)
= Nov 14, 2023, 22:13:20 UTC
Decoding a JavaScript Date.now() value from a bug report
A front-end error report includes a raw Date.now() output. The extra three digits push the count from 10 digits to 13, so the converter switches its assumed unit to milliseconds automatically.
- Input
- 1700000000123
- Detected
- Milliseconds (13 digits)
ISO 8601 = 2023-11-14T22:13:20.123Z
How the unit is detected
There's no header or type tag on a bare integer, so the converter falls back on the same convention most epoch tools use: count the digits. Today's seconds-since-1970 value is 10 digits and won't grow to 11 until the year 2286, so anything that short is read as seconds; a JavaScript-style millisecond count runs three digits longer, and database microsecond or nanosecond fields run longer still. The table below shows the exact cutoffs this page uses.
| Digits | Assumed unit | Example | Represents |
|---|---|---|---|
| 1 – 10 | Seconds | 1700000000 | Nov 14, 2023 |
| 11 – 13 | Milliseconds | 1700000000000 | Nov 14, 2023 |
| 14 – 16 | Microseconds | 1700000000000000 | Nov 14, 2023 |
| 17+ | Nanoseconds | 1700000000000000000 | Nov 14, 2023 |
A minus sign is ignored when counting digits, so negative (pre-1970) timestamps are detected the same way as positive ones.
Frequently asked questions
What exactly is a Unix timestamp?
A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — the "Unix epoch." Software uses it everywhere because it's a single unambiguous integer: no locale, no time zone, no format string to misparse. Two systems anywhere in the world agree on what 1700000000 means, even if they'd never agree on how to read "11/14/2023, 10:13 PM."
How does this converter know if I pasted seconds, milliseconds, or microseconds?
It counts the digits in what you paste. Current-era seconds timestamps are 10 digits (they won't roll over to 11 until the year 2286), so a 10-digit-or-shorter number is read as seconds. Milliseconds timestamps — what JavaScript's Date.now() returns — run 11-13 digits today, and microsecond timestamps (used by some databases and logging systems) run 14-16. The detected unit is shown above the result so you can double-check it guessed right; if a system ever hands you a genuinely ambiguous value, you can still reason it out from the resulting date.
Why did I get a negative number, and what does that mean?
Timestamps aren't limited to 1970 onward. Any instant before the epoch is stored as a negative integer counting seconds backward — for example, -86400 is exactly one day before the epoch: December 31, 1969, 00:00:00 UTC. This calculator handles negative input the same way it handles positive input, so historical dates before 1970 convert correctly.
What is the "Year 2038 problem," and does it affect this tool?
Many older systems store Unix time in a signed 32-bit integer, which overflows at 2,147,483,647 seconds — January 19, 2038, 03:14:07 UTC. One second later, that field wraps to a large negative number and the represented date jumps back to December 1901 on affected systems. This calculator runs in JavaScript, which stores numbers with 64-bit-safe precision internally, so it converts dates well past 2038 correctly — but if you're debugging a legacy 32-bit system (some embedded devices, old databases, or C code using a 32-bit time_t), that system itself may still misbehave at that boundary.
Does Unix time count leap seconds?
No. Unix time defines every day as exactly 86,400 seconds and simply ignores the roughly 27 leap seconds that have been inserted into UTC since 1972 to keep clocks aligned with Earth's slightly irregular rotation. In practice this is treated as a feature, not a bug — it means every day-to-day conversion is a clean, predictable multiply-and-divide by 86,400 without ever needing a leap-second lookup table.
Why do the Local and UTC results show different clock times for the same timestamp?
A timestamp represents one exact, unambiguous instant in time — there's only one epoch number for "right now." Local and UTC are just two different ways of writing that same instant on a calendar: UTC is the reference zero-offset reading, and Local applies your browser's time zone offset (and daylight saving rule, if any) on top of it. Change your device's time zone and the Local column changes, but the underlying epoch number, and the UTC column, never do.