Unix Timestamps: What They Are and Why Every Backend Uses Them
Published July 7, 2026
Prepared by Innealan Editorial
If you’ve worked with any backend system, database, or API, you’ve run into a number like 1735689600 representing a date. That value is 2025-01-01T00:00:00Z. It is Unix time, and understanding the unit prevents a common category of timezone bugs.
The definition
Unix time is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 (the “Unix epoch”), not counting leap seconds. It’s a single, unambiguous integer: no timezone, no daylight saving, no locale.
Why backends prefer it
- Timezone-free by definition. You convert to a human-readable timezone only at the point of display, not storage. This avoids the classic bug where a date shifts by a day depending on the server’s local timezone setting.
- Trivially comparable and sortable. Two timestamps can be compared with simple integer comparison; there’s no need to parse strings or handle calendar arithmetic.
- Compact. A 32-bit or 64-bit integer is far smaller than an ISO string.
Seconds vs milliseconds
Unix/POSIX time is defined in seconds, but JavaScript’s Date.now() and new Date().getTime() return milliseconds. For the same moment, the two values are 1735689600 and 1735689600000. Passing the longer value to a field that expects seconds produces a date far in the future. Passing the shorter value to JavaScript’s new Date() produces a date near 1970.
Write the unit into API field names when you control them: createdAtSeconds is harder to misuse than createdAt.
The Year 2038 problem
Systems that store Unix time as a signed 32-bit integer will overflow at 03:14:07 UTC on January 19, 2038, wrapping around to a negative number (interpreted as December 1901). This mostly affects older C code, embedded systems, and some legacy 32-bit databases. Modern systems using 64-bit integers won’t see this issue until the year 292,277,026,596, a comfortably distant deadline.
Best practice for storing dates
- Store timestamps as Unix time (or ISO 8601 UTC strings) in your database.
- Convert to the user’s local timezone only in the presentation layer.
- Prefer 64-bit integer storage where possible to sidestep the 2038 problem entirely.
Convert between Unix timestamps and human-readable dates, in your local timezone or UTC, with our Unix Timestamp Converter.