Answer: The ⏱ Epoch Converter produces your output instantly from the input you provide — everything runs in your browser, free, with no signup required.
Unix timestamp to human date, and back — seconds or milliseconds
1735689600 = Jan 1, 2025 00:00:00 UTC, and 1000000000 = Sep 9, 2001 01:46:40 UTC. A 10-digit timestamp today means seconds; 13 digits means milliseconds (JavaScript style). The live clock below shows the current epoch right now.
| Epoch (seconds) | UTC Date | Why It Matters |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch itself |
| 86,400 | 1970-01-02 00:00:00 | Exactly one day (86,400 seconds) |
| 100,000,000 | 1973-03-03 09:46:40 | 108 — hundred-millionth second |
| 1,000,000,000 | 2001-09-09 01:46:40 | 109 — billionth second, "billennium" |
| 1,234,567,890 | 2009-02-13 23:31:30 | The sequential-digits moment |
| 1,600,000,000 | 2020-09-13 12:26:40 | Pandemic-era round number |
| 1,700,000,000 | 2023-11-14 22:13:20 | Most recent billion milestone |
| 1,750,000,000 | 2025-06-15 15:06:40 | Round-number epoch from mid-2025 |
| 1,800,000,000 | 2027-01-15 08:00:00 | Next billion milestone (on the hour, oddly) |
| 2,000,000,000 | 2033-05-18 03:33:20 | Two-billionth second |
| 2,147,483,647 | 2038-01-19 03:14:07 | 32-bit signed max — the Y2038 limit |
| Language | Now (seconds) | Parse epoch → date |
|---|---|---|
| JavaScript | Math.floor(Date.now()/1000) | new Date(1735689600 * 1000) |
| Python | int(time.time()) | datetime.utcfromtimestamp(1735689600) |
| Shell | date +%s | date -u -d @1735689600 |
| Go | time.Now().Unix() | time.Unix(1735689600, 0).UTC() |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(1735689600) |
| Unit | Digits today | 2026-01-01 00:00:00 UTC | Where you'll see it |
|---|---|---|---|
| Seconds | 10 | 1767225600 | Unix/POSIX time, date +%s, MySQL UNIX_TIMESTAMP(), Go Unix() |
| Seconds (float) | 10 + decimals | 1767225600.0 | Python time.time(), PostgreSQL extract(epoch from now()) |
| Milliseconds | 13 | 1767225600000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microseconds | 16 | 1767225600000000 | PostgreSQL internal timestamps, many tracing and logging tools |
| Nanoseconds | 19 | 1767225600000000000 | Python time.time_ns(), Go UnixNano(), GNU date +%s%N |
Unix time is a single monotonic count of seconds since 00:00:00 UTC on January 1, 1970 — no timezones, no daylight saving, no calendar math stored. Every timezone conversion happens at display time, which is exactly what this converter does: the timestamp is interpreted against UTC, then rendered in both UTC and your device's local zone.
Paste a timestamp into the top card to read it as a human date, with UTC and local time, the weekday, and a plain-English relative time ("X days ago"). Set the seconds/milliseconds toggle by digit count: 10 digits today means seconds, 13 means milliseconds, and the converter auto-suggests when the magnitude looks wrong. The bottom card runs the other direction; the UTC checkbox controls whether your wall-clock time or UTC is what gets encoded.
Take 1735689600. First sanity-check the magnitude: 10 digits, so seconds. Divide by the seconds in a day — 86,400 — and you get 20,089 days: 55 years of 365 days plus the 14 leap days between 1970 and 2025, landing on 2025-01-01 00:00:00 UTC, a Wednesday. Flip it back: enter 2025-01-01 00:00:00 with UTC checked and out comes 1735689600 seconds, or 1735689600000 milliseconds. For a negative check, 1969-12-31 23:59:59 UTC converts to -1: one second before the epoch.
Counting seconds in a 32-bit signed integer ends at 2,147,483,647 — 03:14:07 UTC on January 19, 2038. After that, unpatched 32-bit systems wrap to negative time and read December 1901. Mainstream 64-bit platforms are past it, but it's a live issue in embedded and legacy code, and it explains why the reference table stops there.
Older C code often stores time in a signed 32-bit time_t. Its maximum, 2,147,483,647, is 03:14:07 UTC on January 19, 2038. One second later the value overflows to −2,147,483,648, read as 20:45:52 UTC on December 13, 1901. Expiry checks and scheduled jobs break.
64-bit platforms use a 64-bit time_t that lasts about 292 billion years, and Linux 5.6 plus glibc 2.34 (_TIME_BITS=64) fixed 32-bit Linux. The leftovers are embedded devices, old file formats and database columns: MySQL's TIMESTAMP type still stops at 2038-01-19 03:14:07 UTC, so long-lived dates belong in DATETIME.
Count the digits. Every seconds timestamp between September 9, 2001 and November 20, 2286 has exactly 10 digits, so any 10-digit number you see in a log is almost certainly seconds. Thirteen digits means milliseconds, 16 means microseconds and 19 means nanoseconds.
Mistakes are easy to spot. Seconds read as milliseconds land in January 1970, while milliseconds read as seconds point tens of thousands of years ahead. If a date is stuck in 1970 or absurdly far off, it's a unit mismatch, not bad data.
No. POSIX time pretends every day is exactly 86,400 seconds long. Since 1972, 27 leap seconds have been added to UTC (the last on December 31, 2016), and Unix time simply ignores all of them. That's why you can get a date from a timestamp with plain division: days = timestamp ÷ 86,400, no lookup table required.
The catch: during a leap second the clock usually repeats a second, so two real instants can share one timestamp. Google and AWS "smear" the extra second over several hours instead. And in 2022, timekeepers voted to stop adding leap seconds by 2035.
SQL: in MySQL, SELECT UNIX_TIMESTAMP(); returns whole seconds. PostgreSQL's SELECT extract(epoch FROM now()); returns fractional seconds; wrap it in floor() for an integer. SQLite uses SELECT strftime('%s','now');, or unixepoch() from version 3.38 on.
Python: time.time() gives a float in seconds; time.time_ns() gives an integer in nanoseconds. Prefer datetime.fromtimestamp(ts, tz=timezone.utc) over utcfromtimestamp(), which is deprecated as of Python 3.12.
Bash: date +%s works on Linux and macOS. On GNU systems, date +%s%3N prints milliseconds.
The Unix epoch is 00:00:00 UTC on January 1, 1970. Unix time counts the seconds elapsed since that moment, so epoch 0 is midnight 1970-01-01, epoch 1000000000 is 2001-09-09 01:46:40 UTC, and timestamps before 1970 are negative numbers.
Divide milliseconds-since-epoch by 1000 if needed, then treat the result as an offset from 1970-01-01 00:00:00 UTC. Example: 1735689600 seconds is 55 years plus 14 leap days (20,089 days), landing on 2025-01-01 00:00:00 UTC, a Wednesday. The converter above does it in either direction, in seconds or milliseconds.
Depends on the system. Unix time proper is seconds. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds, so a 13-digit timestamp means milliseconds and a 10-digit one (today) means seconds. As a rule of thumb: 10 digits = seconds, 13 = milliseconds.
Systems that store Unix time as a 32-bit signed integer max out at 2147483647, which is 03:14:07 UTC on January 19, 2038. After that the counter wraps negative and reads 1901. Most 64-bit systems already use 64-bit time and are unaffected, but embedded systems are the worry.
Historical API design: JavaScript's Date object shipped with millisecond resolution in 1995, and changing it later would have broken the web. So new Date(1735689600) parses the number as milliseconds (January 21, 1970); you need new Date(1735689600 * 1000) for seconds.
No. Unix (POSIX) time treats every day as exactly 86,400 seconds, so the 27 leap seconds added to UTC since 1972 aren't counted. During a leap second the clock repeats or smears a second, which is why Unix time isn't a perfect count of elapsed SI seconds.
Yes. A Unix timestamp is always measured from 1970-01-01 00:00:00 UTC, so the same instant has the same number in Tokyo, London and New York. Time zones only come into play when you format that number as a local date and time.