How to Convert Unix Timestamps to Human Dates

The conversion that goes wrong most often is not the calendar math. It is treating milliseconds as seconds, or printing UTC as if it were the clock on the laptop.

Count the digits first

In the 2020s:

• 10 digits → seconds. Example: 1700000000
• 13 digits → milliseconds. Example: 1700000000000
• 16 digits → microseconds (less common in JS; seen in some databases)
• 19 digits → nanoseconds (Go UnixNano, some tracers)

Date.now() in JavaScript returns milliseconds. time.time() in Python returns seconds as a float. Instant.now() in Java is a seconds-and-nanos pair. APIs that say createdAt: 1700000000 without a unit are doing you no favours; the field name createdAtMs is the documentation.

Rule of thumb: if the “year” comes out as 1970, you divided by 1000 too many times, or you treated a 13-digit value as seconds and then overflowed a 32-bit display. If the year is 50,000+, you treated seconds as milliseconds in reverse (multiplied when you should have divided).

Unix timestamp converter is the page for that check. It runs in the browser; no account.

One numeric check: 1700000000

1700000000 seconds after the epoch is 2023-11-14 22:13:20 UTC.

That is a useful fixture because it is round and recent. Convert it both ways in the tool. Then convert 1700000000000 as milliseconds: you should land on the same instant. Convert 1700000000 as milliseconds and you land on 1970-01-20 11:33:20 UTC - 1.7 million seconds into 1970, which is how “the log says January 1970” bugs are born.

Another fixture: 0 is the epoch itself. 2147483647 is the last second a signed 32-bit Unix clock can represent: 2038-01-19 03:14:07 UTC. If a device reports dates in 1901 or 1970 after a long uptime, look at 32-bit overflow before you look at NTP.

UTC is the timestamp; local is a display

The integer does not know that you are in IST (UTC+5:30) or PDT. Adding 5.5 hours is a display step after you have the UTC instant. Doing it before you know whether the source was already local is how meetings appear on the wrong day.

ISO-8601 strings with a Z (2023-11-14T22:13:20Z) are UTC. Strings with +05:30 already include an offset. Strings with no offset are ambiguous; many parsers treat them as local, which is a different instant for every teammate.

After you have a civil clock time and need another city, use timezone converter. That page is about zones and DST, not about epoch math. The longer DST note is how to convert time across time zones.

Leap seconds and “every day has 86400 seconds”

POSIX time, which almost every web converter implements, pretends leap seconds do not exist. UTC inserts them. For application logs, the discrepancy is rare and small. For satellite or legal timekeeping it is a real specification item. Do not “correct” a Unix converter by adding leap seconds unless you know the timescale (UTC vs TAI vs GPS).

What the converter will not fix

It will not repair a clock that was set to local time and then stored as if it were UTC (the “we subtracted the offset twice” bug). It will not parse 11/14/23 without a format. It will not tell you whether a JWT exp is seconds - though JWT exp is defined as NumericDate in seconds, so a 13-digit exp is already non-compliant.

Copy the result with the zone: 2023-11-14 22:13:20 UTC, not 2023-11-14. The date alone is wrong for anyone west of UTC who is still on the 14th evening.

If you are comparing two logs, convert both to UTC seconds and subtract. Do not subtract two locale-formatted strings.

APIs that return ISO-8601 (2023-11-14T22:13:20.000Z) already did the human-date step. Convert that string to a timestamp only if you need to sort or subtract; do not parse it as local and then store the result as Unix seconds, or you have double-shifted. Spreadsheet date serials (Excel’s 1899-12-30 epoch, or 1904 on old Mac files) are a third system. A value like 45244 is not Unix time.

The unit converters hub will not help; this is time, not pascals. For a map of the other converters, see the student and engineer roundup.