Unix Timestamp Converter
Epoch time ↔ human-readable date, both directions, with the live current timestamp. Seconds or milliseconds detected automatically.
Timestamp → Date
Date → Timestamp
What is Unix time?
Unix time (epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It's the standard clock inside databases, log files, APIs, and programming languages because it's a single unambiguous number — no time zones, no date formats. Milliseconds variants (13 digits instead of 10) are common in JavaScript and Java.
| Timestamp | Meaning |
|---|---|
| 0 | Jan 1, 1970 00:00 UTC — the epoch |
| 1000000000 | Sep 9, 2001 — the "billennium" |
| 1700000000 | Nov 14, 2023 |
| 2000000000 | May 18, 2033 |
| 2147483647 | Jan 19, 2038 — 32-bit overflow ("Y2038 problem") |
Getting the current timestamp in code
If you need a timestamp inside a program rather than a one-off conversion, these are the standard one-liners — note which ones return seconds and which return milliseconds:
| Language | Snippet | Unit |
|---|---|---|
| JavaScript | Date.now() | milliseconds |
| Python | time.time() | seconds (float) |
| PHP | time() | seconds |
| MySQL | UNIX_TIMESTAMP() | seconds |
| Java / Kotlin | System.currentTimeMillis() | milliseconds |
| Shell (Linux/macOS) | date +%s | seconds |
A classic bug: mixing the two units. If a date renders as 1970, you passed seconds where milliseconds were expected; if it lands tens of thousands of years in the future, it's the reverse. Multiplying or dividing by 1,000 fixes it.
Worked example: reading a log file
Say a server log shows 1751673600. It has 10 digits, so it's seconds. Pasting it above gives July 5, 2025, 00:00 UTC — and your local time is shown alongside, which is usually what you actually want when matching a log line to "when did the outage start?" Working the other way, picking July 5, 2025 midnight in the Date → Timestamp box returns the same number, shifted by your time-zone offset.
Seconds or milliseconds? The tool shows both
A bare integer does not say what unit it is in, and getting it wrong moves the answer by a factor of a thousand — which usually means a date in 1970 or a date in the year 55000, both obviously wrong, and occasionally a date that is merely plausibly wrong. Rather than guess and present the guess as fact, this page prints both readings side by side and marks which one it thinks you meant.
The rule of thumb: 10 digits is seconds, 13 digits is milliseconds, and that holds for any date between 2001 and 2286. Where it comes from matters too — JavaScript's Date.now(), Java and most JSON APIs give milliseconds; Unix tools, Postgres, MySQL and log files give seconds.
The year 2038 problem
Unix time was originally stored in a signed 32-bit integer, which runs out at 2,147,483,647 — that is 03:14:07 UTC on 19 January 2038. One second later the counter wraps to negative and the date reads December 1901. This is not a theoretical curiosity: it is the same shape of bug as Y2K, with a hard date attached.
Modern operating systems and languages moved to 64-bit time long ago and are fine for the next 292 billion years. The places it still bites are the ones nobody rewrites: embedded controllers, industrial equipment, old binary file formats, and database columns that were declared INT in 2004 and never touched again. If you are storing a timestamp today, store it in 64 bits — and if you are reading one, this tool flags any value past the 2038 boundary.
Unix time is not the number of seconds that have actually elapsed
This surprises people, and it is worth knowing before you use a timestamp difference as a duration. The POSIX definition computes seconds-since-epoch from the calendar date with a fixed formula that assumes every day is exactly 86,400 seconds long. Real days are not: leap seconds have been inserted 27 times since 1972 to keep clocks in step with the Earth's rotation, which has been slowing irregularly.
Unix time simply ignores them. It repeats or skips a value rather than counting past it, which means the difference between two Unix timestamps is about the elapsed time, off by up to 27 seconds across a span of decades. For scheduling a meeting this is irrelevant; for anything measuring intervals precisely across years, it is a real source of error, and it is why systems that care use TAI or a monotonic clock instead.
The one night a year a local timestamp is genuinely ambiguous
Converting a local date and time to a timestamp assumes that wall-clock time corresponds to exactly one instant. Twice a year in most of Europe and North America, it does not:
- Clocks go forward: an hour is skipped, so a time inside it never happens. Ask a browser for it and it silently answers with a different hour — no error, just a timestamp an hour away from what you meant.
- Clocks go back: an hour happens twice, so the same wall-clock time maps to two different instants an hour apart. The browser picks the first and says nothing.
This tool detects both cases and says which one you are in, giving you the second timestamp when the time is ambiguous. It is also the short answer to why servers, logs and databases keep everything in UTC: UTC has no skipped or repeated hours, so the question cannot arise.
Sources
- The Open Group Base Specifications — Seconds Since the Epoch — the POSIX definition itself, including the formula that treats every day as 86,400 seconds. This is the source for the statement above that Unix time does not count leap seconds; the standard says so explicitly.
- RFC 3339 — Date and Time on the Internet: Timestamps — the ISO 8601 profile used for the formatted output on this page, and the reason a timestamp meant for an API should carry an explicit offset.
- IANA Time Zone Database — the rules your browser uses to decide what your local offset was on any given date, and therefore the source of the daylight-saving behaviour described above.
Frequently asked questions
Seconds or milliseconds — how do I tell?
Count digits: a current-era timestamp has 10 digits in seconds and 13 in milliseconds. This tool detects the difference automatically and labels which one it assumed.
Which time zone is the result in?
Both are shown: your device's local time zone and UTC. The "Date → Timestamp" converter reads the date you pick as your local time.
Can Unix time be negative?
Yes — negative values count backwards from 1970, so -86400 is Dec 31, 1969. This tool accepts them.
What is the year-2038 problem?
Old systems store Unix time as a 32-bit signed integer, which overflows on Jan 19, 2038. Modern 64-bit systems are unaffected for ~292 billion years.
Does Unix time count leap seconds?
No. Unix time pretends every day has exactly 86,400 seconds, so the occasional leap second added by astronomers simply doesn't exist in it. For log files and app timestamps this never matters; only scientific and GPS systems need true atomic time.
How is this different from ISO 8601?
ISO 8601 (e.g. 2025-07-05T00:00:00Z) is a human-readable text format for the same moment a timestamp describes. APIs often accept both; databases usually store the number because it sorts and compares faster.