Unix Timestamp Converter
Convert Unix timestamps to readable dates and back, in local time and UTC, including milliseconds — with the 2038 problem that still lurks in 32-bit systems.
Timestamp → date
| Local time | — |
|---|---|
| UTC | — |
| ISO 8601 | — |
Date → timestamp
| Seconds | — |
|---|---|
| Milliseconds | — |
A bare number does not say whether it is seconds or milliseconds
1700000000 and 1700000000000 are the same instant in different units,
and nothing in either number says which. Every tool has to guess. This one guesses on size:
below 100,000,000,000 it reads seconds, at or above it reads milliseconds.
That threshold is not arbitrary, and what it costs is exactly computable rather than a matter of taste. Read the threshold itself both ways:
| 100,000,000,000 read as | Gives |
|---|---|
| seconds | 5138-11-16T09:46:40.000Z |
| milliseconds | 1973-03-03T09:46:40.000Z |
So the rule is "pick whichever unit gives a date somebody could plausibly mean", and it is
wrong for exactly one set of inputs: a millisecond timestamp below the
threshold, which means an instant between 1970-01-01 and
1973-03-03. A window
3.17 years wide at the very start of the
epoch. From 1973-03-03 onward every millisecond timestamp is read
correctly.
The mirror case is a seconds timestamp at or above the threshold — the year
5138 onwards. Also not a practical worry. If you do have
early-epoch data in milliseconds, multiply by 1000 yourself and paste that.
Input Read as Result 0seconds 1970-01-01T00:00:00.000Z1seconds 1970-01-01T00:00:01.000Z1700000000seconds 2023-11-14T22:13:20.000Z1700000000000milliseconds 2023-11-14T22:13:20.000Z99999999999seconds 5138-11-16T09:46:39.000Z100000000000milliseconds 1973-03-03T09:46:40.000Z
Unix time is not a count of seconds since 1970
This is the part that surprises people who have used timestamps for years. A Unix day is always exactly 86,400 seconds. Not usually — always, by definition.
Real days are not. 27 leap seconds have been inserted since 1972 to keep clocks matched to the Earth's rotation, and Unix time simply does not number them. Subtract two timestamps a decade apart and you get the count of non-leap seconds, which is smaller than the time that actually passed.
The sharpest demonstration is that a leap second has no timestamp at all. The instant below genuinely happened — it is a real UTC time that appeared on real clocks — and it cannot be represented:
| UTC instant | Unix timestamp |
|---|---|
2016-12-31T23:59:59Z | 1483228799 |
2016-12-31T23:59:60Z | no such timestamp |
2017-01-01T00:00:00Z | 1483228800 |
The second before and the second after are consecutive integers with nothing between them. So a Unix timestamp is best read as a label for a calendar instant rather than a duration since the epoch. For calendar arithmetic that is exactly what you want; for measuring elapsed physical time across a leap second it is off by one.
2038, and the limit that actually applies here
| Counter | Runs out at | Then |
|---|---|---|
| signed 32-bit seconds | 2038-01-19T03:14:07.000Z | wraps to 1901-12-13 |
| this page | +275760- | refuses, rather than wrapping |
The famous limit is 2,147,483,647 — the largest signed 32-bit integer — and the next second after it wraps round to December 1901. It does not apply here. JavaScript stores time as a double, which holds every integer millisecond exactly, and the cap is a deliberate one at the year 275760. One millisecond past it you get an error rather than a wrong answer, which is the right way for a limit to behave.
One smaller detail this page gets right: converting a date to seconds uses a floor rather than
truncation. They agree for every date after 1970 and differ before it —
-1500 ms is -2 seconds by
flooring and -1 by truncating. Flooring is correct, because a
timestamp names the second containing the instant.
How to use
- Paste a timestamp in seconds or milliseconds.
- Read the date in both UTC and your local time zone.
- Enter a date to get the timestamp back.
- Check the digit count to tell seconds from milliseconds.
Frequently asked questions
What is a Unix timestamp?
The number of seconds since midnight UTC on 1 January 1970, called the epoch. It is a single integer with no time zone, no daylight saving and no calendar ambiguity, which is exactly why it is the standard way for systems to exchange a moment in time.
Seconds or milliseconds?
Count the digits. A ten-digit timestamp is seconds; thirteen digits is milliseconds. JavaScript uses milliseconds while most other languages and databases use seconds, so mixing the two is a routine bug — a timestamp interpreted with the wrong scale lands either in 1970 or tens of thousands of years hence.
What is the 2038 problem?
A signed 32-bit integer overflows on 19 January 2038, wrapping to a negative number and putting affected systems in 1901. Modern software uses 64-bit timestamps and is unaffected, but embedded devices, old databases and file formats with fixed 32-bit fields still exist. It is a smaller problem than Y2K, and a real one.
Does a timestamp account for leap seconds?
No, and deliberately so. Unix time pretends every day has exactly 86,400 seconds, so a leap second is absorbed by repeating or skipping a value rather than adding one. This keeps the arithmetic simple at the cost of being very slightly out of step with astronomical time.
Why store times as timestamps rather than text?
Because a timestamp is unambiguous and sorts correctly as a number. A date written as text carries format ambiguity, time zone ambiguity, and locale assumptions — 03/04/2026 means two different days depending on which side of the Atlantic wrote it.
What was happening at timestamp zero?
Nothing in particular. 1 January 1970 was chosen as a convenient round date shortly before Unix was written, not to mark any event. Timestamps before it are negative, which is legal and works, though some software handles it poorly.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.