Computers represent time in a way that looks nothing like a calendar: a single, ever-growing number. That number is the Unix timestamp, and it underpins databases, logs, tokens and APIs everywhere. Understanding it removes a lot of confusion around dates and time zones.
The epoch
A Unix timestamp is the number of seconds that have elapsed since midnight UTC on 1 January 1970 — a moment called the epoch. So 1700000000 is simply that many seconds after the epoch. Because it is one number counting steadily upward, it is trivial to store, compare and sort.
Why it is everywhere
Storing time as a single integer sidesteps the messiness of calendars: no months of different lengths, no leap-year edge cases at the storage level, and crucially no time-zone ambiguity, because the timestamp is always in UTC. Converting to a human-readable local time is a presentation concern handled at the edges.
Seconds vs milliseconds
A frequent source of bugs: Unix timestamps are traditionally in seconds, but JavaScript and many APIs use milliseconds. A timestamp that is off by a factor of 1000 puts you either in 1970 or far in the future. Always check which unit a system expects.
The Year 2038 problem
Systems that store the timestamp in a signed 32-bit integer will overflow on 19 January 2038, when the number exceeds what 32 bits can hold — a smaller echo of the Y2K problem. Modern systems use 64-bit timestamps, which push the limit billions of years away, but legacy systems and embedded devices remain at risk and are being migrated.
The practical rule
Store time as a UTC timestamp, convert to local time only for display, and always be explicit about seconds versus milliseconds. Doing so eliminates most date-handling bugs.