Convert between Unix timestamps and human-readable dates.
Unix
1788701184
Milliseconds
1788701184000
ISO 8601
2026-09-06T13:26:24.000Z
UTC
2026-09-06 13:26:24
Relative
0s ago
All calculations performed locally in your browser. No data sent to server.
Results are for informational purposes. Verify results with other sources.
Unix time, and why dates land in 1970
Unix time counts the seconds elapsed since 1 January 1970 UTC. It is a single integer with no time zone attached, which makes it ideal for storage and comparison — and a common source of off-by-a-thousand bugs.
How it works
- Converts between an integer timestamp and a human-readable date in UTC and your local zone.
- Detects the unit from the magnitude: a 10-digit value is seconds, 13 digits is milliseconds, 16 is microseconds, 19 is nanoseconds.
- Ignores leap seconds, as Unix time itself does — a Unix day is always exactly 86,400 seconds.
seconds since 1970-01-01T00:00:00Z 1 000 000 000 → 2001-09-09 (10 digits, seconds) 1 700 000 000 → 2023-11-14 (10 digits, seconds) 1 700 000 000 000 → 2023-11-14 (13 digits, milliseconds) 2^31 − 1 = 2 147 483 647 → 2038-01-19T03:14:07Z
Worked example
The classic bug: a JavaScript timestamp handed to something expecting seconds.
- Date.now() returns 1750000000000 — milliseconds, 13 digits
- passed to a system expecting seconds, it reads as 1,750,000,000,000 seconds
- that is roughly the year 57,442 — or, if the field overflows, 1970
- the fix: Math.floor(Date.now() / 1000) → 1750000000
Whenever a date comes out as 1970 or as an absurd far-future year, the cause is almost always this factor of 1,000. Count the digits before debugging anything else.
Reading the result
- A timestamp has no time zone. Rendering it as a local date is a display decision; the stored integer is always UTC. Two users seeing different dates for the same timestamp is correct behaviour, not a bug.
- Systems storing seconds in a signed 32-bit integer overflow on 19 January 2038. Anything with a long lifetime should use 64-bit.
- Negative timestamps represent dates before 1970 and are valid, but handling varies — some platforms and databases reject or mishandle them.
- Because leap seconds are ignored, Unix time is not a true count of elapsed SI seconds since the epoch. For almost everything this does not matter; for precise interval timing, use a monotonic clock instead.
Common questions
- Why does my date show as 1 January 1970?
- The value reaching the converter was zero, null, or an unparsed string that became zero. It is almost never a genuine 1970 date — check what your code actually passed.
- Seconds or milliseconds — how do I tell?
- Count the digits. Ten digits is seconds and will be a date in the 2001–2286 range. Thirteen is milliseconds. JavaScript uses milliseconds; most Unix tooling, databases and APIs use seconds.