What Is a Unix Timestamp? A Developer's Guide

Open a server log, a database row, or a JWT payload and wherever a date should be, you'll usually find the same thing: a plain integer like 1735689600. No day name, no month, no time zone — just a number that keeps climbing by one every second. That number is a Unix timestamp, and once you know how to read it, values like that stop looking cryptic and start looking exact.

This guide covers what the number actually represents, why it never carries a time zone, how to tell seconds from milliseconds from nanoseconds at a glance, and the overflow bug — the Year 2038 problem — that still catches production systems off guard. If you just need to convert one timestamp right now, the Unix timestamp converter does it instantly; if you want the full picture, keep reading.

A Unix timestamp is the number of whole seconds that have elapsed since a fixed reference instant: 00:00:00 UTC on 1 January 1970, called the Unix epoch. Every moment after that point is a positive, ever-increasing integer; every moment before it is negative. There's no built-in notion of a calendar, a month name, or a day of the week in the number itself — those are all things a program calculates afterward.

You'll see the underlying idea called a few different names — Unix time, POSIX time, and epoch time — used mostly interchangeably. "Epoch" strictly refers to the starting instant itself, while "timestamp" refers to any specific count taken from it, but in practice the terms all point at the same integer.

A concrete example: 1735689600 means exactly one thing, everywhere, on any device, in any time zone — 00:00:00 UTC on 1 January 2025. For the history behind why 1 January 1970 was chosen as the starting line, see Unix Epoch Time Explained.

The original definition counts seconds, but plenty of modern systems need finer resolution, so the same idea just gets scaled. JavaScript's Date.now() returns milliseconds. Databases, tracing systems, and some logging libraries go further, to microseconds or nanoseconds. Each step down multiplies the previous value by 1,000 — and, conveniently, adds three more digits to the number.

Because nothing in the number itself labels its unit, the fastest tell really is just how many digits it has. Paste any timestamp below — the tool guesses the unit from its length and previews the UTC date it points to.

A Unix timestamp counts seconds from one single, fixed instant defined in UTC. It doesn't matter what time zone the server, browser, or phone reading it is set to — the number 1735689600 is the same instant whether it's read in Karachi, London, or Los Angeles. A time zone only enters the picture when that instant gets turned into a human-readable date, because "what time was it locally" depends on where "locally" is. For the reference point every time zone is measured against, see What Is UTC?

Once you know to look for it, the format turns up almost everywhere machines record "when":

• Server and application logs, where each line is stamped with the second (or millisecond) it was written.
• REST and GraphQL API responses, in fields like created_at or updated_at.
• Databases, both relational and NoSQL, storing "when" as a plain numeric column instead of a formatted string.
• JWT tokens, whose iat, exp, and nbf claims are all Unix timestamps in seconds.
• Git commits, which record author and committer time as a Unix timestamp plus a separate time-zone offset.
• Cookies and cache headers that need an expiry instant a program can compare cheaply.

Many older systems store Unix time in a signed 32-bit integer, which can only hold whole numbers from -2,147,483,648 to 2,147,483,647. Counted forward from the epoch, that upper limit lands on 03:14:07 UTC on 19 January 2038. One second later, a 32-bit signed counter that hasn't been upgraded overflows and wraps to a large negative number — which a naive system reads as a date far in the past rather than the present.

Most current systems and languages have moved to a 64-bit representation, which pushes the same kind of overflow so far into the future it isn't a practical concern. The risk sits specifically with older or embedded 32-bit systems that were never updated, which is why the Year 2038 problem is still discussed as a live migration issue rather than settled history.

• Mixing seconds and milliseconds. Passing a millisecond value into a function that expects seconds (or the reverse) produces a date that's off by a factor of 1,000 — often landing thousands of years away from the intended one.
• Assuming the count includes leap seconds. Unix time defines every day as exactly 86,400 seconds and does not count leap seconds, so it isn't a perfectly uniform measure of elapsed physical time across a leap-second event.
• Treating the number as time-zone-aware. It isn't — see the section above. A raw timestamp tells you nothing about local time until you apply an offset.
• Losing precision on very large numbers. JavaScript's safe integer limit is 9,007,199,254,740,991 (16 digits); nanosecond-scale timestamps (19 digits) can exceed it and need careful handling, not plain floating-point math.
• Forgetting negative values are valid. A negative timestamp isn't an error — it's simply a date before 1970.

A Unix timestamp and a human-formatted date solve different problems. The timestamp is compact, sorts correctly as a plain number, and is trivial for a computer to do arithmetic on — but it's unreadable at a glance and says nothing about a time zone by itself. A written standard like ISO 8601 (for example 2025-01-01T00:00:00Z) is readable, sortable as text, and can encode a time-zone offset directly in the string — at the cost of being a longer, more complex format to parse. Most real systems use both: a Unix timestamp internally for storage and math, converted to an ISO 8601 string only where a human or another system needs to read it. For the full breakdown of that format, see The ISO 8601 Date and Time Format, Fully Explained.