Span timestamps trust performance.timeOrigin without the drift guard from #2590 — drifting monotonic clocks produce past-dated (dropped) transactions

[shahzore-qureshi-usmobile]

Summary

createUnixTimestampInSecondsFunc() in @sentry/core (packages/core/src/utils/time.ts) builds the span-timestamp clock as:

const timeOrigin = performance.timeOrigin;
return () => (timeOrigin + withRandomSafeContext(() => performance.now())) / ONE_SECOND_IN_MS;

It trusts performance.timeOrigin unconditionally, with a standing // TODO: This does not account for the case where the monotonic clock that powers performance.now() drifts from the wall clock ....

Meanwhile getBrowserTimeOrigin() (added for #2590 / PR #3356) does validate the origin against Date.now() with a 5-minute threshold before trusting it — but that guarded value feeds browserPerformanceTimeOrigin, not the span-timestamp function above. So the class of bug #2590 set out to fix still reaches production through the span-timestamp path. (Still the case on develop as of this writing.)

Impact

When performance.timeOrigin + performance.now() drifts from Date.now() — the monotonic clock stops while the device/computer sleeps, long-lived process, backgrounded tab (the scenarios #2590 itself described) — every span/transaction is timestamped in the past. Ingest accepts the envelope (HTTP 200) and the backend then silently drops/hides it, so tracing appears "broken" with no client-side error. Errors and sessions (which use dateTimestampInSeconds / Date.now()) are unaffected, which makes this especially hard to diagnose.

Real-world reproduction (React Native 0.86)

On React Native 0.86 (iOS), performance.now() advances only while the process/host is awake while performance.timeOrigin stays fixed wall-clock, so on a long-lived process the sum drifts behind Date.now() by the accumulated sleep. Measured in-app:

performance.timeOrigin            ≈ 2026-07-06   (fixed)
performance.now()                 ≈ 63 h
timeOrigin + performance.now()    ≈ 2026-07-10   ← ~7 days behind
Date.now()                        ≈ 2026-07-17

Every navigation / HTTP / app-start transaction was stamped ~7 days in the past and dropped, while errors were fine. Versions: @sentry/react-native 8.7.0, @sentry/core 10.47.0.

We worked around it app-side by forcing @sentry/core onto its Date.now() fallback (shadowing performance.timeOrigin to 0 when drift is detected). The underlying RN clock behavior is tracked at react/react-native#57595 — but the SDK could be made resilient to any drifting platform clock, which is what this issue is about.

Suggested fix

Apply the drift check that getBrowserTimeOrigin() already implements to the span-timestamp path: in createUnixTimestampInSecondsFunc(), if |timeOrigin + performance.now() - Date.now()| exceeds a threshold, fall back to dateTimestampInSeconds (or re-anchor the origin). That closes the gap left open after #2590 / #3356 and makes span timestamps robust to sleep/drift on every platform, not just RN.

Environment

• @sentry/core 10.47.0 (via @sentry/react-native 8.7.0); the span-timestamp path is unchanged on develop.
• Trigger platform here: React Native 0.86 / iOS — but not RN-specific in principle; any runtime whose monotonic clock drifts from wall time is affected.

Related: #2590, #3356; react/react-native#57595.

[linear-code]

JS-3089