Unix Timestamp

How Unix time works

Unix time counts forward from the epoch at a constant rate: 60 seconds a minute, 86,400 seconds a day, 31,536,000 seconds in a non-leap year. Instants before 1970 are negative numbers. Leap seconds are not counted — every day is exactly 86,400 seconds — which makes timestamp arithmetic trivial:

tomorrow  = now + 86400
last week = now - 7 * 86400

Because the epoch is defined in UTC, a timestamp is inherently a UTC-based quantity. It does not "have" a timezone; converting it to local time is a display concern handled by the IANA timezone database.

Timestamp formats at a glance

Beyond seconds, 64-bit floating-point numbers lose integer precision above 2⁵³ — nanosecond timestamps exceed that. This site converts withBigInt throughout, so 19-digit values are exact.

The 2038 problem

Stored in a signed 32-bit integer, a Unix timestamp overflows at03:14:07 UTC on January 19, 2038 (value 2147483647). One second later it wraps to −2147483648, appearing as December 13, 1901. Embedded systems, old file formats and legacy databases with 32-bit time_t are the remaining risk; mainstream operating systems, languages and databases moved to 64-bit time years ago. A signed 64-bit timestamp lasts roughly 292 billion years — comfortably longer than the universe has existed.

Unix timestamp vs human-readable formats

Textual formats — ISO 8601 (2025-09-16T05:20:00Z), RFC 3339, RFC 2822 — are for humans and logs; timestamps are for machines and math. A good rule of thumb:store timestamps (or UTC instants), render local time at the edges. Never store a local wall-clock reading without its zone; you lose the ability to reconstruct the instant across DST changes.