Nanosecond timestamps don't survive JSON.parse — 99.6% come back changed

Paste this into any browser console:

JSON.stringify(JSON.parse("1753524000123456789"))
// '1753524000123456800'

The input is a nanosecond Unix timestamp: 26 July 2025, 10:00:00.123456789 UTC. The output is a different instant, 11 nanoseconds later. Stranger still, the printed digits are not even the value JavaScript stored — the Number holds 1753524000123456768, 21 nanoseconds earlier, and JSON.stringify prints the shortest decimal that maps back to it. There is no error and no warning, and the result has the right number of digits, so nothing downstream notices.

We measured how often this happens to real timestamps. The answer is almost always.

Why: a double has 53 bits

JSON itself puts no limit on the size of a number. But JSON.parse has to turn each one into a JavaScript Number, which is an IEEE 754 double: 52 stored fraction bits plus an implicit leading one, 53 significant bits in all. Every integer up to 2^53 — 9,007,199,254,740,992 — is exact. Above that, the gap between representable values doubles at every power of two, and the parser rounds to the nearest one.

Nanosecond timestamps crossed 2^53 on 15 April 1970, 104 days after the epoch. Every one since has been rounded; the only question is how coarsely. Between 14 July 2006 and 25 January 2043 they lie between 2^60 and 2^61, where neighbouring doubles are 256 ns apart:

Milliseconds — what Date.now()returns — and microseconds are safe for centuries. Nanoseconds, the resolution of Go's UnixNano()and of OpenTelemetry's timestamps, have been unsafe for practically the whole history of the Unix timestamp.

What we measured

We generated a million nanosecond timestamps spread uniformly across 2026 with a seeded generator, ran each through JSON.parse in Node 26 — the V8 engine Chrome uses — and compared the result with the original digits using BigInt. ECMAScript requires the correctly rounded result for any number of up to 20 significant digits, which covers every 64-bit integer, so every conforming engine produces the same numbers.

That is exactly what the arithmetic predicts. A timestamp survives only if it happens to be a multiple of 256, and one in 256 are: 0.391%. Everything else lands on the nearest multiple, off by up to half the gap.

The error is small; what it does to data is not. We parsed 10,000 events spaced 100 ns apart — one millisecond of a busy service's event stream — and got back 3,907 distinct timestamps. 6,093 events now share a timestamp with a neighbour. Rounding never reverses the order of two events — it is monotonic, and we counted zero inversions — but it makes distinct events simultaneous, so deduplicating by timestamp drops real events and a join on timestamp matches the wrong rows. IDs suffer the same way: Snowflake IDs, Twitter's format that Discord also uses, are 64-bit integers of the same magnitude, so two different IDs can parse to the same Number.

It isn't only JavaScript

Any parser that reads JSON numbers into doubles does this. We fed the same number to the others we had to hand:

Python and Ruby read integers into arbitrary-precision types, so they keep every digit — until the value reaches a JavaScript client. Go is exact with a typed struct and silently lossy with the convenient map[string]any. jq keeps the literal you wrote, but the moment you do arithmetic on it, it is a double. RFC 8259 anticipates all of this: it notes that implementations will agree exactly only on integers within ±(2^53 − 1), and that the way to good interoperability is to expect no more precision than a double provides.

Why the big APIs send strings

This is why APIs that carry 64-bit values put them in quotes. OpenTelemetry's protocol specification says that, following Protobuf's JSON mapping, 64-bit integers in JSON payloads are encoded as decimal strings, and that this “also applies to timestamp fields (such as timeUnixNano…)”. Discord's API reference says its Snowflake IDs “are always returned as strings in the HTTP API to prevent integer overflows in some languages.”

One detail to watch: OTLP decoders must also accept plain numbers, so a sender that writes timeUnixNano unquoted is still valid — and a JavaScript receiver still rounds it. Be strict in what you send.

Four ways to keep every digit

1. Send 64-bit values as strings

The simplest and most portable fix, and the one OpenTelemetry and Discord chose. A string survives every JSON parser in every language, and the consumer converts it with BigInt(), or its language's 64-bit integer type, when it needs to do arithmetic.

2. Use microseconds if you don't need nanoseconds

A microsecond timestamp stays below 2^53 until 5 June 2255, and every one of our million 2026 instants survived as microseconds. If nothing reads the last three digits, dropping them loses nothing you were using.

3. Parse with access to the source text

Modern engines pass a reviver a third argument holding each number's original text, so exact values can be rebuilt as BigInt:

const data = JSON.parse(text, (key, value, context) =>
  typeof value === "number" &&
  !Number.isSafeInteger(value) &&
  /^-?\d+$/.test(context?.source)
    ? BigInt(context.source)
    : value,
);

The integer check matters: 1.5 and 1e20 are not safe integers either, and BigInt() throws on both. The context argument is available in Chrome 114, Firefox 135, Safari 18.4 and Node 21 onwards. On older engines it is undefined, the test fails, and you get the old rounded value rather than an exception.

4. Write exact values back with JSON.rawJSON

JSON.stringify throws a TypeError on a BigInt. JSON.rawJSON wraps a string of digits so that it is emitted unquoted, exactly as written:

JSON.stringify({ t: 1753524000123456789n }, (key, value) =>
  typeof value === "bigint" ? JSON.rawJSON(value.toString()) : value,
);
// '{"t":1753524000123456789}'

It has the same browser support as the reviver context. Our JSON formatter sidesteps the problem entirely — it re-emits the original digits rather than converting them — and flags any integer JavaScript would round, so you can see the problem before it reaches your code. The JSON to table, CSV converter and JWT decoder use the reviver context to keep large numbers exact, and the timestamp converter handles nanoseconds with BigInt throughout.

The rule of thumb

If a number in your JSON can exceed 9,007,199,254,740,991 — 64-bit IDs, nanosecond timestamps, 64-bit counters — send it as a string, and assume at least one consumer is JavaScript. The error is never loud. It averages 64 nanoseconds, it has the right number of digits, and it is a different value.