What Is a Unix Timestamp?

The number that runs the clock of computing

If you have started building with AI and keep running into numbers like 1700000000 in your database rows, API responses, or logs, you have met the Unix timestamp. It looks cryptic, but the idea is simple, and once it clicks you will see it everywhere.

A Unix timestamp is just a count of seconds since one fixed starting point: midnight UTC on January 1, 1970, a moment programmers call "the epoch." So 1700000000 means "1.7 billion seconds after that moment," which lands in November 2023. That is the entire concept. A date, stored as one plain number.

Why computers love it

Storing time as a number instead of text like "November 14, 2023, 10:13 PM" has real advantages:

• No timezone baggage. The number is always counted in UTC, so it means the same instant everywhere on Earth. The timezone is only applied when a human needs to read it.
• Easy to compare and sort. Is one event newer than another? Just compare two numbers. Databases sort millions of rows by time this way, fast.
• Easy to do math. "One hour later" is just "+3600." "How long ago?" is "now minus then." No calendar logic required.
• Compact and universal. Every language and system understands a number, so timestamps travel cleanly between a database, an API, and your app.

Seconds vs milliseconds: the classic trap

Unix time is officially in seconds, which is a ten-digit number today (1700000000). But JavaScript, and many APIs built with it, use milliseconds, a thirteen-digit number (1700000000000). They look similar but differ by a factor of 1000. Feed a milliseconds value into something expecting seconds and your date jumps tens of thousands of years into the future. When a date looks absurdly wrong, this mix-up is almost always why.

Where you actually run into it

For anyone building apps, timestamps show up constantly:

• Databases: created_at and updated_at columns are very often stored as Unix time.
• APIs: responses return times as timestamps so any client can format them locally.
• Auth tokens (JWT): the iat (issued at) and exp (expires) fields are Unix timestamps. If a login "randomly" expires, decode the token and check exp.
• Cookies and sessions: expiry is stored as epoch time.
• Logs: most log lines are timestamped in epoch or ISO form for exact ordering.
• Scheduling and rate limits: "don't run again until timestamp X," or "you can retry after this Unix time."
• Git: every commit records the author and commit time as a Unix timestamp.
• Caches: a TTL is often "expires at this timestamp."

Once you recognize the pattern, half of the mysterious numbers in your code stop being mysterious.

Timezones and UTC

This is where most time bugs are born. A timestamp is one exact instant, but that instant is a different wall-clock time in every timezone. 1700000000 is one moment; in New York it reads as one time, in São Paulo another, in Tokyo another. The number never changes, only the human display does. The rule that saves you: store and send UTC or the raw timestamp, and convert to local time only at the very edge, when showing it to a person.

The year 2038 problem

A bit of trivia with real consequences: older systems store the timestamp in a 32-bit signed integer, which runs out of room on January 19, 2038, when the count exceeds what 32 bits can hold. Modern systems use 64-bit integers and are fine for billions of years, but you may still meet the "2038 problem" in legacy code. It is the epoch's version of Y2K.

How to read and convert one

You cannot eyeball a timestamp, so the practical move is to convert it. Paste the number into the free timestamp converter below and you will instantly see the date in your local time and in UTC, with the seconds-or-milliseconds question handled for you. You can also go the other way, picking a date to get its timestamp, which is handy when you need one for a query or a test.