A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a fixed moment in history known as "the Unix epoch." So the number 1735689600 represents a specific instant: count forward 1,735,689,600 seconds from midnight UTC on January 1, 1970, and you land on January 1, 2025, 00:00:00 UTC. That's it. No timezone offsets baked in, no month names, no ambiguity about whether "01/02/2026" means January 2nd or February 1st. Just one integer that means exactly one instant, everywhere in the world, at the same time.
Human-readable date strings like "March 3, 2026 2:30 PM PST" are great for people and terrible for machines. Consider what a computer has to do to compare two such strings to figure out which came first: parse the month name, resolve the timezone abbreviation, account for daylight saving time, handle multiple possible formats depending on locale. Every one of those steps is a place bugs can hide.
A Unix timestamp sidesteps all of it. Because it's just an integer:
event_a before event_b? Just check timestamp_a < timestamp_b.now + 86400. No calendar logic needed.This is why timestamps are the default internal representation for time almost everywhere: database created_at/updated_at columns, JWT exp (expiry) claims, HTTP cache headers, log file entries, video/audio frame timing, and file system metadata all commonly store epoch time under the hood — even when the UI shows you a friendly formatted date on top.
The concept is universal, but the unit isn't always the same, which is the single biggest source of Unix timestamp bugs:
Date.now() and new Date().getTime() return milliseconds since the epoch — a 13-digit number for present-day dates.time.time() returns seconds since the epoch, as a float (e.g. 1735689600.482913), giving sub-second precision without switching units.created_at column is often a native TIMESTAMP type (Postgres, MySQL, SQL Server all have one) rather than a raw integer, but internally it's still stored as an offset from a reference epoch, and functions like Postgres's EXTRACT(EPOCH FROM ...) or MySQL's UNIX_TIMESTAMP() convert it back to the familiar seconds-based integer.Because JavaScript uses milliseconds while most traditional Unix tooling and many APIs use seconds, mixing the two without converting is one of the most common date-handling bugs in web development — feed a millisecond value where seconds are expected and your date lands near 1970; do the reverse and it lands far in the future.
Older systems that store a Unix timestamp as a signed 32-bit integer can only represent values up to 2,147,483,647 — which corresponds to January 19, 2038, 03:14:07 UTC. One second past that, the value overflows and wraps around to a large negative number, which most systems then interpret as a date back in December 1901. This is the "Year 2038 problem," a spiritual cousin of the Y2K bug.
The good news: modern 64-bit systems store timestamps as 64-bit integers, which can represent dates roughly 292 billion years into the future — effectively a non-issue. The risk is mostly confined to legacy embedded systems, old 32-bit software, and certain file formats/protocols that were designed decades ago and never upgraded their time representation. If you're working with modern language runtimes and databases (Node.js, Python 3, Postgres, MySQL 8+), you don't need to worry about it.
Not sure if a number you're staring at is a valid Unix timestamp? For a present-day date, it should be a 10-digit number (seconds) or 13-digit number (milliseconds). Anything wildly shorter or longer is probably not a standard epoch timestamp — or it's a date far in the past or future.
Paste any Unix timestamp and get local time, UTC, and ISO 8601 instantly — auto-detects seconds vs milliseconds, free and entirely in your browser.
Open Timestamp Converter →-86400 is December 31, 1969. Most modern date libraries handle negative timestamps correctly, though some older or 32-bit-constrained systems may not support dates before the epoch at all.Date constructor expects milliseconds, so passing a seconds-based timestamp directly (new Date(1735689600)) gives you a date in January 1970. Multiply by 1000 first: new Date(1735689600 * 1000).