Almost every computer stores time as a single number: how many seconds have passed since the very beginning of 1970, measured in UTC. That is the whole idea. No time zones, no calendars, no formatting — one integer that ticks upwards.
It is the right design for a computer and unreadable for a person, which is why the number turns up constantly in logs, databases, APIs and export files, and why converting it is such a common errand.
Why 1970
No profound reason. Unix was being built at Bell Labs at the turn of the 1970s and somebody needed a starting point that was recent and round.
The first version counted sixtieths of a second, which sounds precise and overflowed its available range in around two and a half years — so the unit became whole seconds and the origin moved to the start of 1970. That accident is why every timestamp you will ever see is measured from a Thursday morning fifty-odd years ago.
Seconds or milliseconds — the mistake everyone makes once
This is the practical trap, and it is easy to spot once you know the shapes.
Ten digits is seconds. JavaScript, however, works in milliseconds, as do Java and a good deal of what is built on them — thirteen digits is milliseconds.
Hand a millisecond value to something expecting seconds and it reads it as a date around the year 50,000. Hand seconds to something expecting milliseconds and you land in January 1970. Neither produces an error; both produce a confidently wrong date, which is worse.
A converter worth using tells you which it assumed rather than silently picking, because the whole difficulty is that both interpretations are valid numbers.
Reading one at a glance
You cannot convert in your head, but you can sanity-check. Timestamps beginning 17 are in the mid-2020s. Beginning 16, the early 2020s. Beginning 15, the late 2010s. Each leading digit change is roughly three years, which is enough to tell a plausible timestamp from a corrupted one.
A value of 0 is the epoch itself, which is what a missing date frequently becomes. Seeing 1 January 1970 in an interface almost always means a field was empty rather than that something happened in 1970.
Negative numbers are legal and count backwards: −86400 is 31 December 1969. Plenty of systems reject them anyway, which is why birth dates before 1970 have broken so many forms.
2038
A signed 32-bit integer stops at 2,147,483,647. As a Unix timestamp that is 19 January 2038, 03:14:07 UTC, and one second later it wraps round to December 1901.
Anything current uses 64 bits, which pushes the limit past the remaining lifetime of the sun. The problem that remains is in places nobody updates: embedded controllers, old file formats with a 32-bit field baked into the layout, and databases whose column type was chosen in 2003.
It has already caused real failures in systems calculating dates decades ahead — thirty-year mortgages started running into it in 2008.
Leap seconds, and the lie in the definition
The earth's rotation is not quite regular, so leap seconds are occasionally added to keep clocks aligned with it. Unix time ignores them: it is defined as though every day contains exactly 86,400 seconds.
So Unix time is not a count of the seconds that have actually elapsed. It is a count of days multiplied out, which is a subtly different thing, and the difference matters only if you are timing something across a leap second — where the same timestamp can occur twice.
The upside is enormous and is the reason for the choice: converting a timestamp to a date is pure arithmetic, with no table of historical adjustments to consult.
Where you will meet one
Logs and databases, the usual case. Sorting is trivial and comparing is trivial, which is exactly why the format is used.
JWTs, where the expiry claim is a Unix timestamp in seconds. A token rejected as expired is often worth decoding to see what its expiry actually says.
Discord messages. Writing <t:1735689600:F> renders as a full date in every reader's own time zone, and :R renders it as "in 3 hours". It is the neatest solution to scheduling across time zones that any chat platform has, and getting the seconds value is the only fiddly part.
Spreadsheet exports, which is where the seconds-versus-milliseconds confusion usually bites, because the exporting system and the importing one rarely agree.
Converting
A timestamp converter goes both ways and should state which unit it read, since that is the ambiguity. Going the other direction — a date to a timestamp — needs a time zone, because a date without one is not a moment.
That last point catches people: "1 March 2025" is a different timestamp in Tokyo and in Los Angeles. Which is its own problem.
The short version
Seconds since the start of 1970, UTC, ignoring leap seconds. Ten digits is seconds, thirteen is milliseconds. 1 January 1970 in an interface means an empty field. And the counter runs out on 19 January 2038 for anything still using 32 bits.