Microsecond and nanosecond epochs: shortening 16 and 19 digit values

A nineteen-digit number in a trace — time.UnixNano output pasted into a converter and the result that made no sense

A nineteen-digit trace field can be a nanosecond epoch, but pasting it directly into this converter does not test that hypothesis. ToolAcre accepts seconds or milliseconds. Its range error even hints that an oversized database number may use microseconds or nanoseconds, directing the user to normalize before interpreting.

Retain the original text while investigating. Converting it to an ordinary JavaScript Number can already alter low-order digits before any division occurs. The producer’s schema, logging statement or database column definition is better evidence than visual length, especially for counters that are not Unix epochs at all.

The four common resolutions — seconds, milliseconds, microseconds and nanoseconds, with their digit counts for present-day dates

Seconds advance once per second, milliseconds one thousand times faster, microseconds one million times and nanoseconds one billion times. Around present dates these often appear as ten, thirteen, sixteen and nineteen decimal digits. “Often” matters: negative signs, early dates and distant ranges break a digit-only rule.

The panel’s automatic threshold distinguishes only seconds from milliseconds at magnitude 10¹¹. A sixteen-digit microsecond value exceeds that boundary and would be treated as milliseconds, generally exceeding the intended date by a factor of one thousand. Select a unit only after reducing unsupported resolution to one the route names.

Four resolution labels are common, but digit count alone is not a format contract

The outline named several language APIs and storage products, but none is a source file for this tool. Rather than assuming which producer emitted a field, inspect its documentation. A suffix such as `_us` or `_ns`, a declared precision or a known adjacent event supplies evidence that decimal width cannot.

Also distinguish an epoch from a monotonic duration. A high-resolution counter may measure time since process start or boot and have no relation to 1970. Dividing such a value produces a smaller counter, not a calendar date. Confirm both the unit and the origin before bringing the result to an epoch converter.

Identify resolution from the producer, not a list of presumed emitters

To reduce microseconds to milliseconds, remove a factor of 1,000; for nanoseconds, remove 1,000,000. Integer division deliberately sets aside sub-millisecond precision. For a positive value, truncation takes the leading millisecond count. For negatives, choose a rounding rule that matches the producer rather than assuming string slicing has identical semantics.

Do the operation with decimal text or BigInt when precision matters. Floating-point division can begin from an already-rounded nineteen-digit Number. Preserve the discarded remainder beside the converted instant if an investigation needs event order within one millisecond; ToolAcre cannot display those sub-millisecond distinctions.

Worked example: 1700000000123456789 — trimming to milliseconds, reading the result, and noting the sub-millisecond digits you set aside

Take `1738577696123456789` as nanoseconds. Treat it as decimal text, divide by 1,000,000 with integer arithmetic, and obtain 1,738,577,696,123 milliseconds with a remainder of 456,789 nanoseconds. Enter the millisecond quotient explicitly; its ISO reading is `2025-02-03T10:14:56.123Z`.

The remainder is not noise: two trace events can share that displayed millisecond while differing below it. Store the raw values for ordering and use the reduced output only for human orientation. Rounding up to 1,738,577,696,124 would move the displayed instant into the next millisecond and misstate the source.

String division can be reviewed digit by digit: six removed decimal places correspond exactly to the nanosecond-to-millisecond scale, while the untouched prefix remains the calendar-bearing count.

Worked example: preserve a 19-digit value as text while reducing it to milliseconds

JavaScript’s exact-integer guarantee ends well below typical nineteen-digit epoch values. ToolAcre’s parser eventually calls `Number`, so feeding the raw nanosecond text through the panel cannot preserve every digit. Its supported Date limit and unit selector do not turn Number into a nanosecond integer container.

Use BigInt or a string-aware preprocessing path for the reduction, then pass the safely sized millisecond result. This sequencing matters: parsing first and dividing second can corrupt precisely the digits you hoped to retain. A successful calendar rendering does not prove the low-order source value survived.

What this does not cover — clock accuracy, which is unrelated to resolution: a nanosecond timestamp can still be wrong by seconds

Resolution tells you how finely a representation can distinguish values; it does not tell you how close the clock was to physical time. A nanosecond field can be derived from an inaccurate source, while a seconds field can be well synchronized. The converter has no clock-quality measurement and makes no such claim.

Similarly, extra digits can be padded precision rather than measured precision. For incident analysis, compare clocks using synchronization evidence and compare event order using the raw documented counter. The calendar conversion supplies readability only. Do not infer accuracy from a long decimal tail or from three milliseconds shown in ISO.

Takeaway: reduce to milliseconds first, then convert — and how the Unix timestamp converter reads the shortened value with the unit stated

Reduce unsupported resolution before conversion, preserve the original, and state the discarded remainder. ToolAcre can then do what its contract promises: read the resulting seconds or milliseconds and show UTC, local and ISO forms with the selected unit visible.

If the normalized date still makes no sense, revisit the origin rather than repeatedly deleting digits. A counter since boot, another epoch or an undocumented encoding can all remain wrong at every scale. Unit, origin and integer precision are separate questions; answer all three before trusting a human-readable date.

The explicit-unit selector is important after reduction because automatic detection is only a default. Choosing milliseconds records the preprocessing decision instead of asking the magnitude heuristic to rediscover it.