A Unix timestamp has no time zone in it

A Unix timestamp is a count. It is the number of seconds that have elapsed since midnight UTC on 1 January 1970, and it is a single integer with nothing else attached to it. No time zone, no offset, no daylight-saving flag, no locale. That is the whole design, and almost every bug people blame on timestamps comes from forgetting it.

The conversion, on paper

Take 1767225600. A day is 60 × 60 × 24 = 86400 seconds, so divide: 1767225600 ÷ 86400 = 20454 with a remainder of 0. That is 20,454 whole days after 1 January 1970, and no seconds left over, so the time of day is midnight. Feed the day count through the calendar and you get 2026-01-01T00:00:00Z, which is exactly what the tool prints.

The remainder is the clock. Take 2147483647: dividing gives 24855 days and a remainder of 11647 seconds. Split that remainder — 11647 ÷ 3600 = 3 hours, 11647 − 10800 = 847 seconds left, 847 ÷ 60 = 14 minutes, 7 seconds — and the answer is 2038-01-19T03:14:07Z. Two divisions and a lookup. That is the entire algorithm.

Negative numbers work the same way with floor division, so -1 is 1969-12-31T23:59:59Z, one second before the epoch. Dates before 1970 are not a special case; they are just a smaller count.

Where the time zone actually lives

An instant is one thing. The way a person writes it down is another. When it is 2026-01-01T00:00:00Z, a clock in New York reads the previous evening and a clock in Tokyo reads the morning of the second — the same instant, three different sentences. The zone is applied at the moment of display, by whatever library or database driver renders the number, and that step is where the bugs are.

Two rules follow. Store and transmit the integer, or a string that carries an explicit offset; never store a bare local date-and-time string and hope the reader guesses the zone. And when a timestamp comes out wrong by a whole number of hours, look at the display layer, not at the number. The number cannot be wrong by three hours. Something converted it twice, or converted it once with the server's zone instead of the user's.

The mistake you will actually make: seconds against milliseconds

This is the commonest timestamp bug there is, because both values look like plausible timestamps and neither raises an error. Unix time is defined in seconds. JavaScript's Date.now(), Java's System.currentTimeMillis() and most log formats emit milliseconds — the same instant multiplied by a thousand.

Read a millisecond value as seconds and you land absurdly far in the future. 1767225600000, which is New Year 2026 in milliseconds, converts as seconds to 57971-02-25. Read a second value as milliseconds and you land in January 1970: 1767225600 divided by 1000 is 1767225, which is 1970-01-21T10:53:45Z. Those two failure signatures — the far future and the third week of January 1970 — are worth memorising, because they tell you the units are wrong before you have read a line of code.

The quick check is to count digits. For any date in the present era, a seconds value is ten digits and a milliseconds value is thirteen. Divide by 1000 to go down; multiply to go up. This tool takes seconds, and the companion date-to-timestamp tool prints both so you can see the factor of a thousand side by side.

2038, and why it is a storage problem

The largest number a signed 32-bit integer can hold is 2147483647, which is the 2038-01-19T03:14:07Z we worked out above. One second later, a signed 32-bit counter does not become 2,147,483,648 — it wraps to -2147483648, which converts to 1901-12-13T20:45:52Z. A system that stores time in 32 bits does not stop working in 2038; it silently reports a date in 1901.

Modern languages use 64-bit integers and are fine for longer than the question is interesting. The exposure is in storage and interchange: an old database column typed as a 32-bit integer, a binary file format, an embedded device, a protocol field. And it bites earlier than 2038 wherever software already handles future dates — a twenty-year term or a long expiry date crosses the boundary today. If you own a system that stores epoch seconds, the useful question is not what happens in 2038, it is how wide that column is right now.

What this tool does and does not do

It takes seconds and prints two lines: the full UTC instant in ISO 8601 form and the date on its own. There is no time-zone database in it, so it cannot show you the value in Chicago or Kolkata — deliberately, because a zone list that is quietly out of date is worse than no list at all. It does not accept an ISO string as input, and it will happily convert a millisecond value into a year in the far future rather than guessing what you meant.

Nothing is uploaded; Timestamp to Date divides in your browser. The division is the part you keep — once you can do it on paper, a timestamp in a log line stops being opaque.