Unix Timestamp Converter
Convert Unix timestamps to human-readable dates and vice versa.
The Number in Your Log File That Does Not Look Like a Date
You are reading an API response, a database record, or a log file and you see a field with a value like 1719235200. Or maybe 1719235200000. Or 1719235200.847. These are all Unix timestamps — representations of the same moment in time at different precisions. Converting them to a readable date is a daily task for any developer working with APIs, databases, or distributed systems.
What Is the Unix Epoch and Why January 1, 1970?
A Unix timestamp counts the number of seconds elapsed since midnight on January 1, 1970, in Coordinated Universal Time (UTC). This reference point — called the Unix epoch — was chosen by the designers of early Unix systems in the early 1970s as a convenient recent past date. There was no deep significance to January 1, 1970; it was simply a date close to when the system was being designed.
The epoch format became the standard for representing time in computing because it has two critical properties: it is timezone-independent (always UTC), and it is a simple integer that is trivial to compare, add, and subtract. Calculating "how many seconds between two events" is just subtraction. Calculating "what time is 24 hours from now" is just addition. These operations are cumbersome with structured date representations like "January 15, 2025, 3:47 PM EST."
Seconds vs Milliseconds vs Microseconds
The original Unix timestamp counts in seconds. But many modern systems need sub-second precision, leading to two common variants:
- Seconds (10 digits):
1719235200— standard Unix timestamp. Used by most Unix/Linux system calls, POSIX APIs, and many web frameworks. - Milliseconds (13 digits):
1719235200000— seconds multiplied by 1,000. Used by JavaScript'sDate.now(), Java'sSystem.currentTimeMillis(), and most browser and mobile APIs. - Microseconds (16 digits):
1719235200000000— used in high-performance systems, financial data, and some database drivers.
A common bug is treating a millisecond timestamp as seconds. The result is a date approximately 317 years in the future. If your timestamp conversion produces a date in the year 2300, divide by 1,000 first.
Timestamps in JWTs
JSON Web Tokens use Unix timestamps for their time claims. The exp (expiration), iat (issued at), and nbf (not before) claims are all Unix timestamps in seconds. If you decode a JWT and see an exp value you want to verify, convert it here to check whether the token is still valid — or has already expired.
The Year 2038 Problem
On 32-bit systems, a signed 32-bit integer can hold a maximum value of 2,147,483,647. That value as a Unix timestamp corresponds to 03:14:07 UTC on January 19, 2038. After that moment, 32-bit timestamps overflow to a large negative number, causing systems to interpret the time as December 13, 1901. Most modern systems use 64-bit timestamps, which extend to roughly the year 292 billion — well beyond any practical concern. Legacy embedded systems and old 32-bit software remain at risk.
// faq
My timestamp conversion is showing a date in the year 2300 — what is wrong? +
Your timestamp is almost certainly in milliseconds, not seconds. JavaScript and many browser/mobile APIs return timestamps in milliseconds (13 digits). Divide by 1,000 to get seconds before converting. Similarly, a 16-digit timestamp is in microseconds — divide by 1,000,000. A 10-digit number is in seconds and should convert correctly without adjustment.
Why do Unix timestamps not account for time zones? +
That is a feature, not a bug. Unix timestamps always represent a moment in UTC, which makes them timezone-agnostic. Two servers in different time zones that both record the same event will produce identical timestamps. When you display the timestamp to a user, you convert it to the user's local time zone for presentation — but the stored value is always UTC. This is why timestamps are the preferred way to store dates in databases when applications serve users in multiple time zones.
How do I get the current Unix timestamp in my programming language? +
JavaScript: Math.floor(Date.now() / 1000) for seconds, or Date.now() for milliseconds. Python: import time; int(time.time()). PHP: time(). Go: time.Now().Unix(). Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs(). Most languages have a built-in function that returns the current Unix time — check the standard library documentation.
What is the difference between UTC and GMT, and which does Unix time use? +
UTC (Coordinated Universal Time) and GMT (Greenwich Mean Time) are the same offset (UTC+0) for practical purposes, but they are maintained differently. UTC is based on atomic clocks and occasionally has leap seconds added to stay aligned with Earth's rotation. GMT is an astronomical time zone. Unix time is based on UTC and does not count leap seconds — it treats every day as having exactly 86,400 seconds. This means Unix time diverges from true UTC by one second for each leap second that has been added (currently 37 seconds since 1972), but in practice this distinction matters only for precision time applications.
