⏳ Unix Epoch Timestamp Converter
Convert Unix epoch timestamps (seconds & milliseconds) to human-readable UTC and local dates, or convert any date to Unix epoch timestamps. 100% free.
Epoch to Human Date
Human Date to Unix Epoch
What Unix Epoch Timestamp Converter Does
A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, called the epoch. It is a single integer with no timezone, no locale and no ambiguity, which is exactly why almost every system stores time this way and formats it only at the moment of display.
The subtleties are in what it deliberately ignores. Unix time pretends leap seconds do not exist — every day contains exactly 86,400 seconds — so it is not a true count of elapsed physical seconds. During a leap second the same timestamp is used twice.
This converter translates between Unix seconds, milliseconds and human-readable dates in both UTC and your local timezone, and shows the ISO 8601 form.
How to Use Unix Epoch Timestamp Converter
- View the real-time live ticking Unix timestamp at the top
- Enter any epoch timestamp to convert to UTC, ISO 8601, and Local date format
- Or pick any calendar date/time to convert to Unix seconds and milliseconds
Formula Used by Unix Epoch Timestamp Converter
Timestamp to calendar date
date = epoch + (timestamp seconds)
- epoch
- 1970-01-01T00:00:00Z
- timestamp
- Seconds since the epoch; negative values are dates before 1970
Worked example
The timestamp 1000000000.
- 1,000,000,000 ÷ 86,400 = 11,574.07 days
- 11,574 days after 1 Jan 1970 lands on 9 September 2001
- Remainder 0.074 × 86,400 ≈ 6,400 seconds ≈ 01:46:40
Result: 2001-09-09T01:46:40Z — a timestamp widely celebrated when it rolled over.
Seconds or milliseconds?
if timestamp > 100000000000 then it is milliseconds
- 10^11
- A seconds timestamp reaches this only in the year 5138, so anything larger is almost certainly milliseconds
Worked example
Deciding how to read 1735689600 and 1735689600000.
- 1735689600 is below 10^11 → seconds → 2025-01-01T00:00:00Z
- 1735689600000 is above 10^11 → milliseconds → the same instant
Result: Unix tools and most databases use seconds; JavaScript Date.now() and Java use milliseconds. Mixing them shifts dates by roughly 50 years.
Reference Timestamps
| Instant | Unix seconds | ISO 8601 |
|---|---|---|
| Unix epoch | 0 | 1970-01-01T00:00:00Z |
| One billion seconds | 1000000000 | 2001-09-09T01:46:40Z |
| Start of 2000 | 946684800 | 2000-01-01T00:00:00Z |
| Start of 2025 | 1735689600 | 2025-01-01T00:00:00Z |
| 32-bit signed overflow | 2147483647 | 2038-01-19T03:14:07Z |
Precision Units in Common Use
| Unit | Digits (current era) | Used by |
|---|---|---|
| Seconds | 10 | Unix tools, PostgreSQL, most APIs |
| Milliseconds | 13 | JavaScript, Java, MongoDB |
| Microseconds | 16 | Python time_ns/1000, some databases |
| Nanoseconds | 19 | Go, Rust, high-resolution tracing |
How to Read Your Result
The Year 2038 problem
A signed 32-bit integer holds at most 2,147,483,647, which is reached at 03:14:07 UTC on 19 January 2038. One second later it wraps to a negative value and the date reads as December 1901. Most modern systems moved to 64-bit time long ago, but embedded devices, old file formats and unmigrated database columns remain exposed. It is the same class of bug as Y2K, with a firm deadline.
Store UTC, display local
A Unix timestamp has no timezone — it is an instant, not a wall-clock reading. The correct pattern is to store the instant and apply a timezone only when rendering. Storing a local time without its offset is unrecoverable: you cannot later determine which instant "2025-03-30 01:30" referred to in a region where that hour was skipped or repeated by daylight saving.
Leap seconds
Unix time defines every day as 86,400 seconds, so it silently absorbs leap seconds by repeating a value rather than incrementing. It is therefore not a monotonic count of physical seconds, and differences across a leap second are off by one. For measuring elapsed durations, use a monotonic clock instead.
Limitations & Accuracy Notes
- Conversions here use your browser's timezone database for local time. If your device timezone is wrong, local results will be wrong; the UTC output is unaffected.
- Historic dates before about 1970 are handled arithmetically and ignore local calendar reforms and historical timezone offset changes, which were frequent and irregular.
- Negative timestamps are supported by the arithmetic but handled inconsistently across languages and databases. Test before relying on them.
- The tool does not model leap seconds, because Unix time does not represent them.
Frequently Asked Questions
What is a Unix timestamp?
How do I tell if a timestamp is in seconds or milliseconds?
Is my timestamp in seconds or milliseconds?
What is the year 2038 problem?
Does a Unix timestamp have a time zone?
Does it account for leap seconds?
Is my data sent anywhere?
References & Further Reading
- RFC 3339 — Date and Time on the Internet: Timestamps — The internet profile of ISO 8601 used by most APIs