What is a Unix Timestamp?

A Unix timestamp (also called epoch time or POSIX time) counts the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — the Unix epoch. The moment this guide was published is a single integer, not a string that needs parsing, and that integer means the same thing everywhere on Earth regardless of local timezone.

That property — one number, no timezone, no locale, no ambiguous date format — is why it is the default way computers store and exchange points in time internally, even though humans never read it directly.

Reading a timestamp

1751932800  →  2025-07-08T00:00:00Z

To go from the integer to a date by hand: divide by 86,400 (seconds in a day) to get days since the epoch, then count forward from January 1, 1970. In practice nobody does this by hand — every language's standard library converts in one call, and this site's Unix Timestamp Converter does it instantly in both directions.

Seconds vs milliseconds

The one recurring source of confusion: some systems use seconds, others use milliseconds, and a timestamp is just a number with no built-in unit label.

A quick way to tell which one you have without checking docs: a real near-term date in seconds is a 10-digit number (under 10,000,000,000, which corresponds to the year 2286). The same moment in milliseconds is a 13-digit number, three orders of magnitude larger. If the number is 13 digits long, divide by 1000 before treating it as seconds.

Common gotchas

Passing seconds where milliseconds are expected

JavaScript's Date constructor takes milliseconds. new Date(1751932800) does not produce July 2025 — it produces a date about 20 days after the epoch, in January 1970, because the engine reads the value as milliseconds, not seconds:

new Date(1751932800)         // ✗ Wed Jan 21 1970 — treated as ms
new Date(1751932800 * 1000)  // ✓ Tue Jul 08 2025 — converted to ms first

The Year 2038 problem

Systems that store a Unix timestamp as a signed 32-bit integer run out of room at 2,147,483,647 seconds — January 19, 2038, 03:14:07 UTC. One second later, the value overflows and wraps to a large negative number, which most software interprets as December 1901. Modern systems use 64-bit integers, which do not run out until roughly 292 billion years from now, but older embedded systems and file formats are still exposed.

Leap seconds are not counted

Unix time defines every day as exactly 86,400 seconds, full stop. When the International Earth Rotation Service inserts a leap second into UTC to keep clocks aligned with Earth's rotation, Unix time does not gain a corresponding second — the discrepancy is absorbed differently depending on the system (repeating or "smearing" the extra second). For everyday application logic this rarely matters; it matters a great deal for systems that need sub-second precision across a leap-second boundary.

Why not just store a formatted date string?

A string like 07/08/2025 is ambiguous (US month-first vs the rest-of-world day-first convention), locale-dependent, and awkward to do arithmetic on. A Unix timestamp is a plain integer: comparing two events, computing a duration, or sorting a list of events by time is regular number arithmetic, no date-parsing library required. Formatting to a human-readable string is treated as a display concern, done at the last possible moment, in the viewer's own timezone.