⏱️ Unix Timestamp Converter
Paste an epoch value and see the moment it points to — in your time zone, in UTC, and as ISO 8601. Seconds, milliseconds, microseconds and nanoseconds are detected automatically.
Right now
–
Timestamp → date
Date → timestamp
📌 Epoch values worth knowing
| Timestamp | Date (UTC) | What it marks |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch itself — what you see when a field is empty or zero |
| 1000000000 | 2001-09-09 01:46:40 | The "billennium", the first 10-digit second count |
| 1234567890 | 2009-02-13 23:31:30 | A favourite test value because the digits run in order |
| 2147483647 | 2038-01-19 03:14:07 | Largest value of a signed 32-bit integer — the Year 2038 problem |
| 4102444800 | 2100-01-01 00:00:00 | Often used as "never expires" in tokens and cookies |
How to use the timestamp converter
Paste an epoch value into the first box. The unit is guessed from the number of digits, which is right almost every time: 10 digits is seconds, 13 is milliseconds, 16 is microseconds and 19 is nanoseconds. If the guess is wrong — usually because you are looking at a date far in the future or before 1970 — pick the unit from the dropdown and the table recalculates. The second panel runs the other way: choose a date and time, and it reports the epoch value your time zone produces.
What Unix time actually counts
Unix time is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. That is the whole definition. It is a single integer with no time zone, no daylight saving rule and no calendar attached — which is precisely why systems store it. A time zone only enters the picture when a human needs to read the number, and that conversion is what this page does.
| Stored value | Unit | Reads as | Typical source |
|---|---|---|---|
| 1793620746 | seconds (10 digits) | 2026-11-02 09:19:06 UTC | PHP time(), Python time.time(), MySQL UNIX_TIMESTAMP() |
| 1793620746000 | milliseconds (13 digits) | same moment | JavaScript Date.now(), Java System.currentTimeMillis() |
| 1793620746000000 | microseconds (16 digits) | same moment | Python time.time_ns() // 1000, PostgreSQL extract(epoch) |
| 1793620746000000000 | nanoseconds (19 digits) | same moment | Go UnixNano(), Java Instant.getNano() combined values |
The 1000× bug
Almost every "my date is wrong" bug is one of two things. Feeding JavaScript a 10-digit seconds value makes new Date(1793620746) land in January 1970, because the constructor expects milliseconds. Feeding a 13-digit milliseconds value to a function that expects seconds throws the date about 55,000 years into the future. Before debugging anything else, count the digits.
Assumptions and limitations
Output is shown in two forms: your browser's local time zone, and UTC. Neither is "more correct" — they are the same instant rendered differently, so the only question is which one the person reading it expects. Range is limited by JavaScript's Date, roughly ±8.64 × 1015 milliseconds (about 275,000 years either side of 1970); values beyond that display as invalid. Leap seconds are ignored, in line with POSIX, so a timestamp can never be off by more than a second relative to UTC. For a longer walk-through of the mistakes people make with epoch values, see our article Unix Timestamps: Timezones, Formats and Pitfalls.
Frequently Asked Questions
Why does my timestamp show 1970?
Because the value is being read in the wrong unit. A 10-digit number is seconds; JavaScript's Date constructor wants milliseconds, so new Date(1793620746) is interpreted as 1,793,620,746 ms — about 20 days after the epoch, not 2026. Multiply by 1000 before constructing the date, or divide a millisecond value by 1000 before handing it to a seconds-based API. Truncating instead of rounding is fine here; a sub-second error only matters for logging.
Does Unix time change with time zones or daylight saving?
No. A Unix timestamp is an absolute instant, identical on every machine on Earth. Time zones and DST exist only in the formatting layer. That is why two servers in different regions can log the same integer and still show different clock times — and why you should store timestamps, not formatted date strings, in a database. One caveat: if you build a timestamp from a local date string, the offset at that moment does affect the result, which is why parsing "2026-11-02 09:00" without an explicit zone is ambiguous.
What is the Year 2038 problem?
Many older systems store Unix time in a signed 32-bit integer, whose maximum is 2,147,483,647 — 03:14:07 UTC on 19 January 2038. One second later the value overflows and wraps to a large negative number, so the date jumps to 1901. Most 64-bit systems are already safe (a 64-bit counter lasts about 292 billion years), but embedded devices, old databases and legacy file formats are not. The practical fix is to audit storage types now rather than in 2037.
How do I get a timestamp in code?
JavaScript: Math.floor(Date.now() / 1000) for seconds, Date.now() for milliseconds. Python: int(time.time()). PHP: time(). Go: time.Now().Unix(). SQL: UNIX_TIMESTAMP() in MySQL, EXTRACT(EPOCH FROM now()) in PostgreSQL. If you need a specific moment rather than now, parse an ISO 8601 string with an explicit offset — for example Date.parse("2026-11-02T09:00:00Z") / 1000 — so the result does not depend on the machine's local zone.
🛒 Recommended for You
As an Amazon Associate, Benditools earns from qualifying purchases.