Unix Timestamp (Epoch Time) Explained — How to Convert
If you have ever seen a number like 1735689600 where you expected a date, you have met a Unix timestamp. It is how most computers, databases, APIs and log files store time under the hood. This guide explains what epoch time is, why it exists, the famous "Year 2038 problem," and how to convert a timestamp to a human date (and back).
What a Unix timestamp is
A Unix timestamp — also called epoch time, POSIX time or Unix time — is simply the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. That starting moment is called the Unix epoch.
So 0 is midnight on 1 Jan 1970 (UTC), 86400 is exactly one day later, and 1735689600 is 1 January 2025. Because it is one single counting number, it is easy to store, compare and do maths with.
Want to see it live? Our Epoch / Unix Timestamp Converter turns any timestamp into a readable date and any date into a timestamp instantly.
Why computers use epoch time instead of dates
Storing "14 March 2026, 9:30 AM, Cairo time" is messy — it mixes a calendar, a clock and a timezone, in a human language. A timestamp sidesteps all of that:
- It is unambiguous. One number means one exact instant worldwide, with no timezone confusion.
- It is easy to compare. "Which event is newer?" becomes a simple "which number is bigger?"
- It is easy to do maths on. "How long between these two events?" is just a subtraction.
- It is compact. One integer takes far less space than a formatted date string.
That is why you will find timestamps in databases, JWTs, cookies, API responses, server logs and file metadata everywhere.
Seconds, milliseconds and other precisions
A classic gotcha: not every timestamp is in seconds. Different systems use different precision, and mixing them up is one of the most common time bugs.
| Unit | Example | Digits (today) | Where you see it |
|---|---|---|---|
| Seconds | 1735689600 | 10 | Unix tools, databases, JWT exp |
| Milliseconds | 1735689600000 | 13 | JavaScript Date.now(), Java |
| Microseconds | 1735689600000000 | 16 | Python, high-resolution logs |
Quick rule of thumb: a 10-digit number is seconds, a 13-digit number is milliseconds. If a date comes out in 1970 or thousands of years in the future, you probably mixed up the unit.
Timestamps are always UTC — timezones come later
A Unix timestamp has no timezone. It is an absolute point in time, defined in UTC. The timezone only matters when you display it: the same timestamp 1735689600 is "1 Jan 2025, 00:00 London" and "1 Jan 2025, 02:00 Cairo" — same instant, different wall clocks. This is exactly why storing time as a timestamp and converting to local time only for display avoids a whole category of bugs. To move a human time between zones, use our Timezone Converter.
Converting a timestamp to a date (and back)
The quickest way is our Epoch Converter, but here is how it works in common languages:
- JavaScript:
new Date(1735689600 * 1000)— remember JS uses milliseconds, so multiply seconds by 1000. - Python:
datetime.utcfromtimestamp(1735689600), andint(datetime.now().timestamp())to go back. - PHP:
date('Y-m-d H:i:s', 1735689600), andtime()orstrtotime('2025-01-01')to get a timestamp. - SQL: most databases have
FROM_UNIXTIME()/to_timestamp()functions. - Command line:
date -d @1735689600on Linux.
The Year 2038 problem
Older systems store the timestamp in a signed 32-bit integer, which can only count up to 2,147,483,647 seconds. That limit is reached at 03:14:07 UTC on 19 January 2038 — after which the number overflows and wraps around to a negative value, sending the date back to 1901. It is the modern echo of the Y2K bug.
The fix is already widespread: move to a 64-bit timestamp, which pushes the limit roughly 292 billion years into the future. Most current operating systems, languages and databases already use 64-bit time, but legacy embedded systems are the ones to watch.
Where you will meet timestamps as a developer
- JWTs: the
iat(issued-at) andexp(expiry) claims are Unix seconds — decode one with our JWT Decoder or read what a JWT is. - Cookies and caches: expiry is often stored as epoch seconds.
- Logs: many log formats prefix each line with a timestamp.
- APIs:
created_atandupdated_atfields are frequently epoch values.
Frequently asked questions
Why does the epoch start in 1970?
It is the date the engineers who built early Unix at Bell Labs chose as a convenient, recent zero point. It stuck, and it is now a standard across almost all computing.
My timestamp converts to the year 1970 — what went wrong?
You likely passed milliseconds to a function expecting seconds (or vice-versa), so the number was a thousand times too small. Check the digit count: 10 = seconds, 13 = milliseconds.
Do Unix timestamps count leap seconds?
No. Unix time deliberately ignores leap seconds and assumes every day is exactly 86,400 seconds. This keeps the maths simple, at the cost of being a tiny amount off from precise astronomical time.
Can a timestamp be negative?
Yes. Dates before 1 January 1970 are represented as negative seconds — for example, -86400 is 31 December 1969.
Is epoch time the same everywhere in the world?
Yes. A given timestamp is the same instant globally; only the local date and time you display it as changes with the timezone.
The bottom line
A Unix timestamp is just a count of seconds since 1 January 1970 UTC — a simple, timezone-free, easy-to-compare way to store an instant. Watch out for the seconds-vs-milliseconds trap and the 2038 limit on old 32-bit systems, store time as UTC and convert only for display. To convert any timestamp right now, use our Epoch / Unix Timestamp Converter, and for moving times between zones try the Timezone Converter.
