Nanosecond Timestamp Converter. Nanoseconds and Microseconds to Date.

Why this page exists when the main converter already reads nanoseconds

The main epoch converter detects the unit from the digit count and will accept a 19-digit value. It is the right tool for reading one and moving on. This page exists for the cases where the sub-millisecond digits are the entire point: verifying that a nanosecond counter is producing the value you think it is, comparing two timestamps that differ only below the millisecond, or converting a log line where the resolution is the interesting detail.

There is a specific reason those cases need a separate implementation rather than a flag on the existing one. JavaScript numbers hold integers exactly only up to 9,007,199,254,740,991, and a 19-digit nanosecond timestamp is about two hundred times that. Reading such a value into a Number and dividing by a million produces a millisecond figure that is usually right while the low digits have already been rounded away in silence, with no error and no warning. Working in BigInt removes the possibility rather than papering over it.

What the arithmetic actually does

Conversion works by integer division and remainder, never by scaling a float. A nanosecond count is divided by a billion to get whole seconds, and the leftover is the fraction within that second. The seconds are floored toward negative infinity first, which is the detail that makes pre-1970 values come out right: the fraction is then guaranteed to land in the range zero to one billion minus one, so it can be written directly into the fractional part of an ISO string. Dividing a negative value and truncating toward zero would instead produce a fraction outside that range and a timestamp on the wrong side of the second boundary.

The same care applies in the other direction. A date typed in with up to nine fractional digits is split into whole milliseconds, which a Date can hold, and the leftover digits, which it cannot. The two are kept apart and recombined as integers, so 2026-08-07T12:00:00.123456789Z becomes a nanosecond count whose last six digits are exactly 456789 rather than a value rounded to the nearest microsecond. A tenth fractional digit is rejected rather than rounded, because a nanosecond clock has nowhere to put it.

Nanosecond units do not mean nanosecond resolution

A field measured in nanoseconds is a statement about the unit, not about the accuracy of the clock behind it. Most hardware time sources are far coarser: a typical PC timer resolves to about a microsecond, a modern CPU counter to tens of nanoseconds, and the system clock synchronised over the network to a millisecond or two. A 19-digit timestamp whose low nine digits are almost all zeros is not a malfunction, it is a millisecond measurement reported in nanoseconds.

The same caution applies to the Now button here. It reads the browser's own high-resolution timer, which is genuinely finer than Date.now() and gives microsecond resolution, but it is still a wall clock derived from the operating system and not a hardware counter reading. Treat it as a good microsecond reading and not as a true nanosecond one.

Telling the sub-second units apart

Every sub-second Unix timestamp is an integer count since 1970, and the only thing distinguishing one from another is how many digits it has. Ten digits or fewer is seconds. Eleven to thirteen is milliseconds. Fourteen to sixteen is microseconds. Seventeen to nineteen is nanoseconds. The counts drift upward as the decades pass, so a rule written against today's values slowly misreads tomorrow's, which is why the digit thresholds are worth checking against a known date rather than trusting forever.

Two of the neighbouring formats on this site use the same sub-second units with a different epoch, and that is a more dangerous confusion than the unit itself. Windows FILETIME and the historical Chromium DOM timestamp both count microseconds since 1601, not since 1970 — a gap of 11,644,473,600 seconds, which is more than three hundred years. A microsecond value read with the wrong epoch lands somewhere in the sixteenth century instead of the twenty-first, and no amount of unit detection will catch it.

Nanosecond Timestamp Converter. Nanoseconds and Microseconds to Date. — questions from actual use

How many digits is a nanosecond timestamp?

Nineteen, for any date between roughly the year 2001 and the year 2262. A nanosecond count from 1970 passes ten billion, which is eleven digits, at the one-second mark, and reaches nineteen digits during 2001. Microseconds from 1970 pass a million at the same instant, so a microsecond timestamp is sixteen digits across that same window. These digit counts are the basis of the unit auto-detection on the main epoch converter on this site.

Why does converting a 19-digit number in JavaScript give the wrong answer?

Because a JavaScript number is a 64-bit floating-point value that stores integers exactly only up to 9,007,199,254,740,991, which is sixteen digits. A nanosecond timestamp is roughly two hundred times larger than that limit, so the low digits are rounded off silently and without any error being raised. Multiplying by a million to reach milliseconds does not help either, because the precision was already gone. The fix is to hold the value as a BigInt and do the division and remainder with integer arithmetic, which is what this converter does.

Which systems actually emit nanosecond timestamps?

A good number of them, which is why the format is worth handling explicitly. Go makes it easy to reach for nanoseconds through time.Now().UnixNano(). Java carries Instant with up to nanosecond precision. Linux system calls, many databases, and high-frequency trading and telemetry systems all expose nanosecond or microsecond clocks. The trap is that the underlying hardware clock is usually far coarser than the unit it is reported in, so a nanosecond field is frequently a millisecond-resolution measurement with zeros in the low digits.

What is the difference between microseconds since 1970 and microseconds since 1601?

Only the epoch, and it is a difference of eleven thousand million seconds, so getting it wrong produces a date hundreds of years out. Microseconds since 1601 is the Windows FILETIME unit, and it is what Chromium and WebKit historically used for DOM timestamps — that format has its own converter on this site. Microseconds since 1970 is the conventional Unix unit that this page handles. At the epoch, the 1601 form reads 11,644,473,600,000,000 and the 1970 form reads zero.

Can this converter handle dates before 1970?

Yes, and the arithmetic is done in a way that makes the negative side correct rather than approximately correct. Whole seconds are floored toward negative infinity before the fractional part is taken, so an instant 1.5 milliseconds before the epoch renders as 1969-12-31T23:59:59.998500000Z. Truncating the division instead would place that value on the wrong side of the second boundary, and a sub-millisecond remainder is reported alongside so you can confirm the digits landed where you expected.