Unix Timestamp Converter

A number turned up in a log line and nobody knows what it means

A support ticket arrives quoting one field out of an HSS lookup: "lastSeen": 1786602497, and nothing around it says what that is. It is a Unix timestamp — seconds since midnight UTC on 1 January 1970 — and it works out to 13 August 2026 at 06:28:17 UTC. Paste it on the left and you get that back straight away, in whichever time zone you pick, plus a relative reading so you can tell at a glance whether the event is recent.

The awkward part is that 1786602497 and 1786602497000 are the same instant in different units, and nothing about either number says which. Counting digits is the only signal available: ten is seconds, thirteen milliseconds, sixteen microseconds, nineteen nanoseconds. Which one you meet depends on where the value came from — Date.now() gives milliseconds, PostgreSQL stores timestamps to microsecond resolution, and tracing spans routinely carry nanoseconds.

So this page reports the unit it read rather than quietly applying it. Seconds read as milliseconds lands you in January 1970; milliseconds read as seconds lands you around the year 58,600. Both are wrong in a way you spot instantly. It is the microsecond and nanosecond mix-ups that hurt, because they produce plausible dates in the wrong decade and you can stare at one for a long time without noticing. A chip reading read as milliseconds, plus a control to overrule it, closes that gap for nothing.

Nineteen digits is where a lot of converters quietly break. A JavaScript number is an IEEE-754 double, so anything past Number.MAX_SAFE_INTEGER loses its tail: Number('1786602497123456789') evaluates to 1786602497123456800 before any division happens. The split into seconds and sub-second digits here is string arithmetic, so the last three digits you typed are still the last three you get back — the same failure mode that breaks long numbers in JSON, on timestamps instead of identifiers.

It converts the other way too. Type a date and you get the epoch back in all four units, plus the reading the runtime actually applied — and a bare 2026-08-13 gets both interpretations side by side, because those are two different instants. Zones come from the IANA time zone database through the browser's own Intl implementation, so Europe/Berlin is +01:00 in January and +02:00 in July rather than a fixed number that is wrong half the year.

Converting a timestamp

1. Paste the number, or the date – A bare integer is treated as an epoch timestamp; anything else is treated as a date string. Both directions update as you type, so there is no convert button to hunt for.
2. Check the unit chip – It tells you what the digit count implied. If the count did not match one of the four standard lengths, a grey note says so — that is the case where a guess is genuinely a guess.
3. Override the unit if you know better – The Unit control forces seconds, milliseconds, microseconds or nanoseconds. Useful for an old timestamp whose digit count no longer matches its unit — a 2001 timestamp in milliseconds is only twelve digits.
4. Pick the time zone you care about – The zoned ISO row re-renders in any IANA zone, with that zone's real offset for that instant, daylight saving included.

The most common way this goes wrong in JavaScript is new Date(1786602497). The constructor takes milliseconds, so a seconds value gives you 21 January 1970, which then gets blamed on the database. Multiply by 1000 first. On the command line the trap is different: GNU date -d @1786602497 and BSD/macOS date -r 1786602497 do the same job with incompatible flags, and the wrong one on the wrong platform errors out rather than answering wrongly — the better failure of the two.

One ten-digit number, expanded

The value from the ticket above. Ten digits, so the unit is unambiguous and the chip reads read as seconds with nothing else to say about it.

1786602497

ISO 8601 (UTC)
2026-08-13T06:28:17.000Z

RFC 2822
Thu, 13 Aug 2026 06:28:17 GMT

Epoch milliseconds
1786602497000

When this comes up

Reading a timestamp buried in a payload you already have open

CDRs, session records and provisioning responses are full of raw epoch fields — startTime, lastSeen, expiresAt — none of them readable as they stand. Open the document in JSON to Table for the whole structure, then paste the one field you care about here.

Matching a log line against a database row

The application log prints milliseconds, the database column holds microseconds, and the same event ends up as two values three orders of magnitude apart. Converting both here and comparing the readable dates is quicker than working out which one needs dividing — and removes the risk of dividing the wrong one.

Checking a spreadsheet export that came back wrong

Spreadsheets do not use the Unix epoch at all — they count days from 1899 or 1904 — so a timestamp column that went through Excel often comes back as a five-digit serial rather than a ten-digit epoch. If your export looks nothing like the numbers here, that is usually why; Excel to JSON handles it on the way out.

Pinning a timestamp into a test fixture

The Now button gives you the current epoch in seconds to paste straight into a test. A constant beats Date.now() in a fixture, because a test that generates its own timestamp cannot fail the same way twice.

What this page does

• Converts in both directions from one input — a bare integer is read as an epoch, anything else as a date string.
• Names the unit it detected, and marks it as a guess when the digit count matched none of the four standard lengths instead of silently picking one.
• Keeps nineteen-digit nanosecond values exact by splitting them as text, so the sub-second digits you typed survive the round trip.
• Renders any instant in any IANA time zone using that zone's real offset for that date, so a summer and a winter timestamp are not given the same one.
• Shows both readings of a bare YYYY-MM-DD side by side, with the gap between them.
• Runs entirely in your browser — the timestamps you paste are never sent anywhere.

Questions people actually ask

Why does my timestamp come out as 1 January 1970?

You have handed a seconds value to something expecting milliseconds, or the value was empty and got coerced to zero on the way. A seconds timestamp read as milliseconds lands a short way into January 1970, which is why so many bug reports name that month specifically. Set the Unit control to Seconds and you will see the date it should have been.

What is the year 2038 problem, and does it affect me?

A signed 32-bit time_t — still the type behind the C time() call on older systems — overflows on 19 January 2038 and wraps round to 1901. Anything 64-bit is fine, and so is a JavaScript number. It bites embedded firmware and old database columns typed as INT, which is why a 2038 expiry date is worth testing for deliberately rather than waiting for.

Why does a date without a time land on the wrong day?

Because a bare 2026-08-13 and 2026-08-13T00:00:00 are not the same instant: the date-only form is defined as UTC and the date-time form without an offset as local time. West of Greenwich the first one formats as the 12th. Paste a bare date on the left and both readings appear together with the gap between them.

Can it handle timestamps from before 1970?

Yes. A leading minus is a real timestamp, not a typo — a date of birth stored as an epoch value is negative for anyone born before 1970, and treating the minus as a parse failure is a bug people report.

Does it round nanosecond timestamps?

No, and that is the main reason this page exists rather than a three-line snippet. A nineteen-digit value is past the range a double represents exactly, so anything running it through Number() or parseInt() has already lost the last two or three digits before it does anything useful. The seconds part and the fractional part are separated as strings here, and only the seconds part — eleven digits at most — is ever converted to a number.

Related tools

Specifications and references

• ECMA-262 — Date Time String Format – The clause that makes a bare date UTC and a date-time without an offset local
• RFC 3339 — Date and Time on the Internet – The profile of ISO 8601 that most APIs actually mean when they say ISO
• MDN — Date.parse() – Including the warning that anything outside the standard formats is implementation-specific