Seconds or milliseconds
Unix time counts from 1 January 1970 UTC. Most back ends count seconds; JavaScript counts milliseconds. Feed one to the other and you land in 1970 or somewhere around the year 56,000.
The quick test: a current timestamp in seconds is 10 digits, in milliseconds 13. Both are detected here, so pasting either gives a sensible answer.
The timezone that is not there
A Unix timestamp has no timezone. It is a count of seconds since a fixed instant, identical everywhere on earth. What varies is how it is displayed — the same number is 15:00 in London and 23:00 in Shanghai.
Which is why storing timestamps rather than local date strings avoids a whole class of bug. Both readings are shown here so you can see the difference rather than guess at it.
2038
A signed 32-bit timestamp overflows on 19 January 2038 and wraps to 1901. Modern systems use 64 bits and are fine for longer than the sun has left, but embedded devices, old database columns and some file formats still use 32.
It is worth knowing if you are storing dates far in the future — a 30-year mortgage entered today already crosses it.
Frequently asked questions
Is my timestamp in seconds or milliseconds?
A current one is 10 digits in seconds and 13 in milliseconds. Both are handled here. Mixing them up puts your date in 1970 or tens of thousands of years out.
Does a Unix timestamp have a timezone?
No. It is the same number everywhere on earth; only the display differs. That is exactly why storing timestamps beats storing local date strings.
What is the 2038 problem?
A signed 32-bit timestamp overflows on 19 January 2038 and wraps to 1901. 64-bit systems are unaffected, but old columns, embedded devices and some file formats are not.
Why is my date one day out?
Almost always a timezone difference around midnight — the same instant falls on different dates depending on where you read it. Compare the UTC and local rows shown here.
Something wrong with this tool, or an idea for it? Tell us