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) |
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.
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.