A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. Right now, that number is somewhere around 1.77 billion. Every date and time in every system you have ever used is, at some layer, backed by a number like this.
The simplicity is its strength. A single integer represents a moment in time unambiguously, independent of time zones, date formats, calendar systems, or locale. But that simplicity hides a collection of edge cases that have caused some of the most famous bugs in computing history.
Seconds vs. milliseconds
JavaScript's Date.now() returns milliseconds since epoch. Most Unix systems use seconds. This is the source of approximately 40% of all timestamp bugs I encounter.
Date.now() // 1774000000000 (milliseconds)
Math.floor(Date.now() / 1000) // 1774000000 (seconds)
If you pass a millisecond timestamp to a function expecting seconds, you get a date in the year 58,000. If you pass seconds to a function expecting milliseconds, you get a date in January 1970 (or December 1969 if you are in a western time zone).
Always check whether a timestamp is in seconds (10 digits circa 2026) or milliseconds (13 digits).
The Year 2038 problem
Unix timestamps are traditionally stored as a 32-bit signed integer. The maximum value of a 32-bit signed integer is 2,147,483,647, which corresponds to January 19, 2038, at 03:14:07 UTC. One second later, the integer overflows and wraps to a large negative number, which represents December 13, 1901.
This is not a theoretical concern. Embedded systems, legacy databases, and any system using 32-bit time_t will fail in 2038. The fix is simple in concept (use 64-bit integers) but complex in practice (every system in the chain must be updated).
Modern systems mostly use 64-bit timestamps, which overflow in the year 292 billion. That should be sufficient.
Converting to human-readable dates
The conversion from timestamp to human-readable date requires a time zone. The timestamp 1774000000 is a specific moment in time, but:
- In UTC: a specific date and time
- In US Eastern (UTC-5): 5 hours earlier on the clock
- In Japan (UTC+9): 9 hours later on the clock
The date might even differ. 1774000000 at 2:00 AM UTC is still "yesterday" in Pacific time.
const ts = 1774000000;
const date = new Date(ts * 1000);
console.log(date.toISOString()); // UTC
console.log(date.toLocaleString()); // Local time zone
console.log(date.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' })); // Specific zone
Negative timestamps
Timestamps before January 1, 1970 are negative. July 20, 1969 (Apollo 11 moon landing) is approximately -14182940. Not all systems handle negative timestamps correctly. JavaScript does. Some databases and APIs do not.
Leap seconds
UTC occasionally adds a leap second to keep atomic time aligned with Earth's rotation. 27 leap seconds have been added since 1972. Unix timestamps ignore leap seconds entirely -- they pretend every day has exactly 86,400 seconds.
This means that during a leap second, the Unix timestamp either repeats a value or skips one, depending on implementation. For most applications, this is irrelevant. For high-precision timing systems, it matters.
Common conversion tasks
Developers constantly need to convert between formats:
- ISO 8601 string to timestamp:
new Date('2026-03-25T12:00:00Z').getTime() / 1000 - Timestamp to ISO 8601:
new Date(ts * 1000).toISOString() - Human-readable to timestamp: parsing "March 25, 2026 at 3:00 PM EST"
- Relative time: "2 hours ago" from a timestamp
I built a timestamp converter at zovo.one/free-tools/timestamp-converter that converts between Unix timestamps (seconds and milliseconds), ISO 8601, RFC 2822, and human-readable formats in any time zone. Paste a timestamp, see the date. Pick a date, get the timestamp. It handles the conversions that every developer needs weekly.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)