A Unix timestamp is a single integer: the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, the moment known as the epoch. Because it is one number with no timezone, no locale and no formatting, it is what systems use to agree on when something happened — databases, log files, JWT claims and HTTP headers all store time this way and leave the formatting to whatever displays it.
The most common mistake is the unit. Unix timestamps are traditionally in seconds and are 10 digits long today (1754784000). JavaScript's Date.now(), Java's System.currentTimeMillis() and most JSON APIs return MILLISECONDS instead, which is 13 digits. Feeding a millisecond value into a seconds-based parser lands you in the year 57000; feeding seconds into a millisecond parser lands you in January 1970. If a converted date looks absurd, count the digits first.
A timestamp itself has no timezone — it is always UTC. The timezone only enters when you render it, which is why the same integer shows as 21:00 in Istanbul and 18:00 in London. That separation is the point: store the instant, format at the edge. Converting a local date back to a timestamp is where offsets have to be applied explicitly, and where daylight-saving transitions produce the two classic bugs — an hour that happens twice, and an hour that never happens at all.
Signed 32-bit systems cannot count past 03:14:07 UTC on 19 January 2038, when the value overflows and wraps to 1901. This is the Year 2038 problem, and it is not hypothetical for embedded devices, older C code and any schema that still stores time in a 32-bit INT. Modern platforms use 64-bit integers, which postpones the question by about 292 billion years.
This converter runs entirely in your browser: the value you paste is never sent to a server, which matters when the timestamp came out of a production log. It reads seconds and milliseconds, and outputs ISO 8601, UTC and your local time together so the offset is visible rather than assumed.
