fix: #2147 preserve sub-millisecond precision in trace waterfall timestamps

[nquandt]

fix: #2147

Summary

Move parseTimestampToMs to src/utils.ts and import it in DBTraceWaterfallChart. Uses TimestampNano to avoid truncation from new Date().getTime(), preventing alignment errors when two events fall within the same millisecond.

Screenshots or video

Before:

After:

How to test locally or on Vercel

1. Run the docker build for hyperdx-local
2. Send some spans and traces with less than ms precision
3. See alignment in waterfall before and after applying change.

References

#2147

[vercel]

@nquandt-mt is attempting to deploy a commit to the HyperDX Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 58ee458

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

<!-- claude-code-review -->

PR Review

✅ No critical issues found.

Small, well-scoped fix with good test coverage (zero-sub-ms, fractional ms, max boundary, ordering). The getTime() + (getNano() % 1_000_000) / 1_000_000 math correctly recovers sub-millisecond precision, and all three call sites in DBTraceWaterfallChart were updated consistently. Tests appropriately use toBeCloseTo to account for Float64 precision at modern epoch magnitudes.

Minor (non-blocking) observations:

• parseTimestampToMs doesn't guard against invalid input — but neither did the prior new Date(...).getTime(), and callers feed it server-provided ISO strings, so behavior parity is fine.
• Sort comparator in rows still constructs TimestampNano directly rather than reusing the new helper; that's intentional (helper returns lossy float, comparator needs exact int compare), so no change needed.

[nquandt]

After fighting with the Claude Code Review bot, I think this is in a good spot. I have no further changes at this time.

[brandon-pereira]

@karl-power are you able to take a look at this? You have the most experience with trace waterfall atm

[karl-power]

LGTM @nquandt

Can you fix the conflict?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hyperdx-oss	Ready	Preview, Comment	May 6, 2026 2:19pm

[github-actions]

PR Review

✅ No critical issues found.

Minor observations (optional, not blocking):

• 💡 The same file (DBTraceWaterfallChart.tsx) still imports TimestampNano directly for the sort at line 520-521. Could be migrated to a shared helper for consistency, but the current sort logic uses getTimeT()/getNano() separately so it's a different API surface — fine to leave for a follow-up.
• 💡 parseTimestampToMs silently relies on TimestampNano.fromString accepting whatever shape result.Timestamp arrives in. Existing code already does this on the same values (sort path), so behavior is consistent — no action needed.

Math verified: toDate().getTime() truncates to ms, then (getNano() % 1_000_000) / 1_000_000 adds back the sub-ms fraction. Tests cover the common cases (no sub-ms, sub-ms only, ms+sub-ms, max value, ordering within the same ms).

[nquandt]

@karl-power all done and ready for a squash 👍

[brandon-pereira]

Thanks for the contribution! 🥳