A Unix timestamp is just a number: seconds elapsed since midnight UTC, January 1, 1970. No timezone, no format ambiguity, no locale issues — which is exactly why it's the right choice for storing timestamps in a database or passing them between services. ISO 8601 (2026-09-16T14:30:00Z) is the human-readable equivalent, and the right choice for logs, APIs consumed by humans, or anywhere you need the timezone to be explicit and unambiguous rather than implied.
Seconds vs milliseconds — the actual bug
This is where almost every timestamp bug comes from. 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 treats it as epoch milliseconds without converting will render a date somewhere in 1970, because a value like 1758030600 interpreted as milliseconds is about 20 days after the epoch, not 2026.
// 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, but it's worth knowing why the date sounds 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.