Unix timestamp converter
Epoch seconds in, human date out — or the reverse. Both directions show UTC alongside your local time, because mixing them up is the usual bug.
Seconds since 1970, and the two traps
A Unix timestamp counts seconds from midnight UTC on 1 January 1970. Because it is anchored to UTC, the same number displays as a different wall-clock time depending on where you are — which is exactly why both are shown above.
The first trap is seconds versus milliseconds. JavaScript works in milliseconds and produces 13-digit numbers, while most APIs and databases use 10-digit seconds. Feeding one to something expecting the other lands you in 1970 or somewhere around the year 54,000. This converter detects the length and handles either.
The second is the 2038 problem: signed 32-bit timestamps overflow on 19 January 2038. Modern systems use 64-bit values and are fine, but old embedded devices and legacy database columns are not, and it is worth knowing if you work with either.
The Discord tag is included because it is the most common practical use of a timestamp outside code — paste it in a message and every reader sees their own local time.
Questions
Seconds or milliseconds?
Ten digits is seconds, thirteen is milliseconds. This detects which you pasted and converts either, but check what the system you are feeding expects.
Why does the time differ from what I expected?
Timestamps are anchored to UTC. Both your local time and UTC are shown above — if they differ from your expectation, the offset is almost always the reason.
What is the 2038 problem?
Signed 32-bit timestamps run out on 19 January 2038. Anything modern uses 64-bit values and is unaffected, but legacy hardware and old database schemas may not be.