Date & Time
Unix Timestamp Converter
Paste a Unix timestamp to see it as an ISO 8601 string, a UTC date, your own local time, and a plain-English relative time like 3 days ago. The unit is detected from the number's size, so seconds, milliseconds, microseconds, and nanoseconds all just work — and you can override it when you know better. Convert the other way by entering a date and time in UTC or your local zone, and grab the current epoch from the live clock at the top.
Epoch time right now
0
0 in milliseconds ·
Timestamp to date
Tap any row to copy it.
ISO 8601 (UTC)
UTC
Your local time
Relative
Seconds
Milliseconds
Day of week
Day of year
ISO week
Quarter
Date to timestamp
Your local timezone is .
\nSeconds
Milliseconds
ISO 8601 (UTC)
What is a Unix timestamp?
A Unix timestamp — also called epoch time or POSIX time — counts the seconds that have passed since 1 January 1970 at 00:00:00 UTC. Because it is a single number with no timezone, no calendar, and no daylight-saving rules attached, it is the format databases, log files, APIs, and JWTs almost always store. Turning it back into a human date is where a timezone finally gets applied, which is why the same number reads differently for you and for a colleague in another country.
Seconds or milliseconds?
Unix itself counts seconds, and so do most backend languages, JWT exp claims, and database timestamp columns. JavaScript's Date.now() counts milliseconds, and Go and Rust often deal in microseconds or nanoseconds. A ten-digit number is almost always seconds, thirteen digits is milliseconds, sixteen is microseconds and nineteen is nanoseconds — which is exactly the rule this converter applies before you touch anything. If a date comes out in 1970, you have handed a millisecond value to something expecting seconds.
The year 2038 problem
Systems that store the timestamp in a signed 32-bit integer run out of room at 03:14:07 UTC on 19 January 2038, one second after which the counter wraps to a negative number and the date jumps back to 1901. Modern 64-bit systems are unaffected and will keep counting for roughly 292 billion years, but embedded devices, old file formats, and legacy database columns are still worth checking.
Negative timestamps and leap seconds
Dates before 1970 are perfectly valid as negative numbers, and this converter handles them — the moon landing is -14182940. One thing Unix time deliberately ignores is leap seconds: every day is treated as exactly 86,400 seconds, so the count is a smooth arithmetic line rather than a true count of elapsed SI seconds. That trade-off is what makes date maths simple, and it is why UTC and Unix time drift by a few dozen seconds over decades.
Frequently asked questions
How do I know whether a timestamp is in seconds or milliseconds?
Count the digits. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds, and nineteen is nanoseconds, for any date in the current era. This converter applies that rule automatically and tells you which reading it used, and you can override it from the unit menu if your value is unusual.
Why does my date come out as 1 January 1970?
Because the value being converted is effectively zero or very small — usually a millisecond timestamp that was passed to something expecting seconds, or an empty field that became 0. Dividing a thirteen-digit value by 1000 before it reaches a seconds-based API fixes it.
What is the year 2038 problem?
Systems that store Unix time in a signed 32-bit integer cannot count past 03:14:07 UTC on 19 January 2038. One second later the value overflows into a negative number and the date reads as 1901. Anything running 64-bit timestamps is unaffected, but old embedded systems and legacy database columns can still be caught out.
Can a Unix timestamp be negative?
Yes. Negative values count backwards from 1 January 1970, so they represent dates before the epoch — the Apollo 11 landing is around -14182940. Some older systems reject negative timestamps, but the format itself has no problem with them and this converter handles them.
Does Unix time account for leap seconds?
No, and that is deliberate. Every day is treated as exactly 86,400 seconds, so the count is a smooth arithmetic line rather than a true tally of elapsed seconds. It makes date arithmetic simple at the cost of drifting from atomic time by a few dozen seconds since 1972.