A Unix timestamp is a number: seconds elapsed since midnight UTC on January 1, 1970. It has no timezone, no format ambiguity, and no locale issues, which makes it a good choice for storing timestamps in a database or passing them between services. ISO 8601 (2025-09-16T13:50:00Z) is the human-readable equivalent. Use it for logs, for APIs that people read, and anywhere the timezone needs to be stated instead of implied.
Seconds vs milliseconds
Most timestamp bugs come from this. Unix time is defined in seconds. JavaScript's Date.now() and new Date().getTime() return milliseconds. A backend that stores epoch seconds and a frontend that reads them as epoch milliseconds without converting will render a date in 1970. A value like 1758030600 read as milliseconds is about 20 days after the epoch. Read as seconds, it's September 16, 2025.
// backend gives you epoch seconds: 1758030600 new Date(1758030600) // wrong — treats it as ms, gives 1970-01-21 new Date(1758030600 * 1000) // correct
The Y2038 problem, briefly
A signed 32-bit integer overflows at 2147483647, which corresponds to 2038-01-19T03:14:07Z. Systems still storing epoch time as a signed 32-bit int (some embedded systems, some older C code) will wrap around to a negative number at that point. Most modern systems use 64-bit integers and don't have this problem. That overflow is why the date is so oddly specific when it comes up.
Always store UTC, convert for display
Store and pass timestamps in UTC (either epoch, or ISO 8601 with a Z or explicit offset). Convert to the viewer's local timezone only at the point of display. Storing “local time” without a timezone attached is how you end up with an hour of ambiguity around DST transitions that's effectively unrecoverable later.