2026-09-07 · 6 min read · Rahul Chitturi
- time
- api
- debugging
An event timestamp can preserve the right second while silently losing milliseconds, microseconds, or nanoseconds. Sorting then becomes unstable, optimistic boundaries collide, and logs from different services appear to happen in the wrong order.
The loss may occur during parsing, numeric conversion, database storage, serialization, or display, so the visible string is only one boundary in the investigation.
Write down precision and units
For each hop, record whether the value is ISO text or an epoch number, its unit, accepted fractional digits, rounding or truncation behavior, timezone meaning, database type, and language runtime representation.
- Do not infer seconds versus milliseconds from magnitude alone
- Keep epoch integers out of floating-point paths when exactness matters
- Distinguish stored precision from displayed precision
- Specify whether extra fractional digits fail, round, or truncate
Compare one instant at every boundary
Use a synthetic instant with non-zero digits at every supported fractional position. Capture the source object, serialized bytes, parsed runtime value, bound database parameter, stored value, selected value, and final response.
Add a stable tie-breaker when ordering events because even perfectly preserved timestamps can be equal. Precision is not a uniqueness guarantee and does not establish causality across machines.
A Flashman workflow
Use the timestamp converter for ISO and epoch inspection, JSON formatter to expose strings and numbers, diff for each round trip, units converter for unit changes, and number-base converter for bounded integer fixtures.
Test zero and maximum fractions, values around second boundaries, negative epochs if supported, database round trips, language and driver upgrades, sorting ties, and exact API serialization.