How to Convert a Unix Timestamp to a Date and Back
A Unix timestamp is an integer that counts the number of seconds since 1970-01-01 00:00:00 UTC (the Unix epoch), not counting leap seconds. In JavaScript, convert it to a human-readable date by multiplying by 1000 (to get milliseconds) and passing it to new Date() (to go back, divide the date's UTC milliseconds by 1000). In Python, pass the seconds directly to datetime.fromtimestamp(seconds, tz=timezone.utc).
Seconds vs milliseconds: telling them apart
The single most common source of confusion with Unix timestamps is the unit. APIs return seconds; JavaScript's Date.now() returns milliseconds; databases often store one or the other without saying which. The quickest way to distinguish them is to count the digits:
| Digit count | Unit | Example value | Approximate date |
|---|---|---|---|
| 10 | Seconds | 1700000000 | 2023-11-14 UTC |
| 13 | Milliseconds | 1700000000000 | 2023-11-14 UTC |
| 16 | Microseconds | 1700000000000000 | 2023-11-14 UTC |
| 19 | Nanoseconds | 1700000000000000000 | 2023-11-14 UTC |
A 10-digit value in seconds covers dates from 2001 to 2286, which is by far the most common range today. The Unix Timestamp Converter detects the unit automatically from the magnitude and tells you which one it used. You can always override the detection with the unit selector.
Step-by-step walkthrough
Identify the unit from the digit count
A 10-digit value is almost certainly seconds. A 13-digit value is milliseconds. The Unix Timestamp Converter detects this automatically, or you can override it with the unit selector.
Paste the epoch value and read the date
In the Unix Timestamp Converter, paste the number into the epoch input. The tool shows the UTC date, local time, ISO 8601 string, and a relative description such as "3 days ago".
Convert a date string to epoch time
Type or paste an ISO 8601 date such as 2026-10-28T00:00:00Z into the date input. The converter shows the Unix seconds and milliseconds for that moment. Include a timezone offset such as Z or +05:30 for unambiguous results.
Verify against UTC, not local time
A Unix timestamp always measures elapsed time from 1970-01-01 00:00:00 UTC. When displaying it, explicitly pass a timezone to avoid the output shifting based on the machine running the code.
Check the year 2038 limit for 32-bit systems
A signed 32-bit integer tops out at 2,147,483,647 seconds, which corresponds to 2038-01-19 03:14:07 UTC. Modern environments are not affected (JavaScript Date uses a 64-bit float and Python integers have no fixed size), but older embedded systems and 32-bit database columns like MySQL INT or TIMESTAMP may be.
UTC vs local time
A Unix timestamp is always in UTC. It has no timezone of its own — it is simply a count of seconds. The timezone only matters when you format the timestamp as a human-readable string. If you omit the timezone argument, most environments default to the machine's local timezone, which makes the formatted output unpredictable when code runs on servers in different regions.
// seconds → ISO 8601 (UTC)
const seconds = 1700000000;
new Date(seconds * 1000).toISOString();
// "2023-11-14T22:13:20.000Z"
// ISO 8601 → seconds
const ms = Date.parse("2023-11-14T22:13:20Z");
const secs = Math.floor(ms / 1000);
// 1700000000from datetime import datetime, timezone
# seconds → ISO 8601 (UTC)
seconds = 1700000000
dt = datetime.fromtimestamp(seconds, tz=timezone.utc)
dt.isoformat()
# "2023-11-14T22:13:20+00:00"
# ISO 8601 → seconds
dt2 = datetime.fromisoformat("2023-11-14T22:13:20+00:00")
int(dt2.timestamp())
# 1700000000Always pass tz=timezone.utc in Python or append Z to your ISO string in JavaScript. The Unix Timestamp Converter shows the UTC date above your local time so you can compare them.
ISO 8601 format
ISO 8601 is the international standard for date and time strings. The most useful form for timestamps is the combined date-time format with a timezone designator:
2026-10-28T14:30:00Z ← UTC (Z = +00:00) 2026-10-28T20:00:00+05:30 ← IST (UTC+5:30) 2026-10-28T22:13:20.000Z ← UTC with milliseconds
JavaScript's Date.toISOString() always returns the UTC form ending in Z. The converter's ISO 8601 output field copies this string so you can paste it directly into JSON payloads, database columns, or log entries.
Timestamps before 1970
Negative Unix timestamps represent moments before the epoch. For example, -86400 is one day before the epoch, which is 1969-12-31 00:00:00 UTC.
JavaScript's new Date(negativeSeconds * 1000) handles negative values directly. In Python, however, calling datetime.fromtimestamp() on negative values may raise an OverflowError or OSError depending on what the host platform's underlying C library handles (often restricted to years in 1970 through 2038). To handle pre-1970 timestamps reliably everywhere in Python, add a timedelta to the epoch:
from datetime import datetime, timezone, timedelta # Safely handle pre-1970 timestamps across all platforms epoch = datetime(1970, 1, 1, tzinfo=timezone.utc) dt = epoch + timedelta(seconds=-86400) # 1969-12-31 00:00:00+00:00
The Unix Timestamp Converter handles negative inputs seamlessly.
The year 2038 problem for 32-bit systems
A signed 32-bit integer tops out at 2,147,483,647. In Unix seconds, that maximum value corresponds to 2038-01-19 03:14:07 UTC. One second later, the 32-bit counter overflows and wraps to a large negative number, which most systems interpret as a date in 1901.
Neither JavaScript nor Python is affected: a JavaScript Date is backed by a 64-bit float of milliseconds (good for ±8.64e15 ms, reaching the year 275,760), and Python's integers have arbitrary precision with no fixed size. The risk remains in legacy 32-bit C software, embedded firmware, and database columns. Note that in MySQL, the native TIMESTAMP type also tops out at 2038-01-19 03:14:07 UTC; affected columns should migrate to BIGINT or DATETIME (which goes up to the year 9999).
// Frequently Asked Questions
How do I tell seconds from milliseconds?
Count the digits of the absolute value. A 10-digit timestamp (up to about 9,999,999,999) is seconds and covers dates up to 2286. A 13-digit value is milliseconds. The Unix Timestamp Converter auto-detects the unit from the magnitude and shows which one it used.
What does a negative Unix timestamp mean?
A negative timestamp represents a moment before 1970-01-01 00:00:00 UTC. For example, -86400 is 1969-12-31 00:00:00 UTC, exactly one day before the Unix epoch. JavaScript's Date handles negative milliseconds directly. In Python, fromtimestamp() may raise OverflowError or OSError depending on platform C library limits, so datetime(1970, 1, 1, tzinfo=timezone.utc) + timedelta(seconds=...) is safer and works everywhere.
What is the year 2038 problem?
A signed 32-bit integer tops out at 2,147,483,647, which corresponds to 2038-01-19 03:14:07 UTC. After that second, the counter overflows and wraps to a negative number representing 1901. Modern environments are safe: JavaScript's Date is a 64-bit float (good to year 275760) and Python ints have arbitrary precision. Vulnerabilities remain in 32-bit C binaries, legacy embedded hardware, and database columns like MySQL INT or TIMESTAMP (migrate to BIGINT or DATETIME).
What is ISO 8601 and how does it relate to Unix timestamps?
ISO 8601 is an international standard for date and time strings, for example 2026-10-28T14:30:00Z. The trailing Z means UTC. You convert a Unix timestamp to ISO 8601 with new Date(seconds * 1000).toISOString() in JavaScript or datetime.fromtimestamp(seconds, tz=timezone.utc).isoformat() in Python (which outputs a +00:00 offset). The converter copies the ISO 8601 string directly from its output panel.
Why does the converter show a different time from what I expected?
The most common reason is a unit mismatch: a millisecond value interpreted as seconds gives a date far in the future, and a second value interpreted as milliseconds gives a date in early 1970. The second most common reason is a local time offset: the UTC output is always correct, but the local time panel depends on the timezone of the device viewing the page.