Unix Timestamp Converter
Convert epoch timestamps to dates and back, in any timezone.
Your timezone is Asia/Karachi. The date picker reads as local time; the UTC row shows the same instant without the offset.
About this tool
Convert an epoch timestamp into a readable date, or go the other way. Seconds and milliseconds are detected automatically, and results are shown in both UTC and your local timezone so off-by-one-day bugs are obvious.
How to use it
- Paste a timestamp, or pick a date and time.
- Read the conversion in UTC, local time and ISO 8601.
- Copy whichever format your code needs.
Seconds, milliseconds, and how to tell them apart
Unix time counts seconds since 1 January 1970 UTC. JavaScript's Date.now() returns milliseconds. Mixing them is the single most common bug in date handling, and the symptom is memorable: a timestamp interpreted as seconds instead of milliseconds lands in 1970, and one interpreted the other way lands around the year 55,000.
Telling them apart is easy by length, at least for current dates:
- 10 digits — seconds (until November 2286)
- 13 digits — milliseconds
This tool uses that heuristic and tells you which it detected. Some systems also use microseconds (16 digits) or nanoseconds (19 digits); Go and some tracing tools emit those.
If you see a date in 1970 in production, you are almost certainly dividing or multiplying by 1000 in the wrong place.
The 2038 problem and why leap seconds do not exist here
2038. Systems storing Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, wrapping to 1901. This is a real concern for embedded systems and old C code, and irrelevant for anything using 64-bit time — which includes JavaScript, modern Linux, and every current database.
Leap seconds are ignored. Unix time pretends every day is exactly 86,400 seconds. Real UTC occasionally inserts a leap second, so Unix time is not a true count of elapsed seconds since 1970 — it is off by the number of leap seconds since then. Systems handle this by repeating or smearing a second rather than incrementing the counter.
In practice this means you should never compute precise durations across a leap second from Unix timestamps, and you should never be surprised that two systems disagree by a second during one.
Negative timestamps are valid and represent dates before 1970. Some libraries handle them badly, which is why birthdates before 1970 occasionally break registration forms.
Frequently asked questions
- Seconds or milliseconds?
- Unix time is seconds; JavaScript's Date.now() returns milliseconds. A ten-digit number is almost certainly seconds and a thirteen-digit one milliseconds, which is how this tool guesses.
- What is the 2038 problem?
- Systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038. Anything using 64-bit time — which includes JavaScript — is unaffected.
- Is anything sent anywhere?
- No. The conversion uses your browser's own Date object, and your timezone is read from your system rather than looked up over the network.