Description
Per the High Resolution Time spec, performance.timeOrigin + performance.now() should approximate the current wall-clock time (Date.now()). On React Native 0.86 (iOS), once the app process has been alive across host/device sleep, that sum drifts behindDate.now() by roughly the total sleep duration — performance.now() appears to advance only while the process/host is awake, while performance.timeOrigin stays a fixed wall-clock value, so their sum lags.
Measured in the JS runtime on a long-lived iOS 27 simulator:
performance.timeOrigin ≈ 2026-07-06 (fixed, ~boot wall time)
performance.now() ≈ 63 h (awake time only)
timeOrigin + performance.now() ≈ 2026-07-10 ← ~7 days behind
Date.now() ≈ 2026-07-17
So timeOrigin + performance.now() was ~7 days in the past, and grows with accumulated sleep.
Impact
Any library that reconstructs an absolute timestamp as timeOrigin + performance.now() gets timestamps in the past. Concretely, @sentry/core timestamps every span/transaction this way (its createUnixTimestampInSecondsFunc), so all performance transactions were stamped ~a week in the past and were silently dropped/hidden by the backend, while errors and sessions (which use Date.now()) were unaffected. This was very hard to diagnose because ingestion accepts the events (HTTP 200) and only drops them later.
Steps to reproduce
- iOS app on RN 0.86 whose JS process stays alive across periods of host/device sleep (a long-lived simulator reproduces this readily; a real device backgrounded across sleep should too).
- In the JS runtime, read and compare:
constdrift=performance.timeOrigin+performance.now()-Date.now();console.log('drift(ms):',drift);// grows with accumulated sleep
Expected
performance.timeOrigin + performance.now() stays ≈ Date.now() (within a small tolerance), per the HR-Time spec — i.e. either now() should include suspended time, or timeOrigin should be defined consistently with the clock backing now().
Actual
timeOrigin + performance.now() lags Date.now() by the accumulated sleep time (observed up to ~7 days).
Notes / caveats (honest about what I could and couldn't confirm)
- I have not been able to pin this to a specific RN source change.
ReactCommon/react/nativemodule/webperformance/NativePerformance.cpp (now() → HighResTimeStamp::now(), timeOrigin → unsafeOriginFromUnixTimeStamp()) and react/timing/primitives.h (backed by std::chrono::steady_clock) look materially the same between 0.83.4 and 0.86.0. So this could be a libc++/toolchain change in steady_clock behavior, or environment-specific — maintainer insight very welcome. - Data point: an app on RN 0.83.4 on the same machine/simulator did not exhibit the drift (
timeOrigin + now() ≈ Date.now(), drift ~0), whereas RN 0.86.0 did (drift ~7 days). Same @sentry/react-native 8.7.0 / @sentry/core 10.47.0 in both. - I don't yet have a standalone minimal reproducer outside our app — happy to build one and answer any questions.
Environment
- React Native: 0.86.0 (via Expo SDK 57)
- Platform: iOS (iOS 27 simulator)
- macOS: 27.0 · Xcode: 27.0 (27A5218g) · Node: 24.14.0
- Compared against: React Native 0.83.4 (no drift, same machine)
Description
Per the High Resolution Time spec,
performance.timeOrigin + performance.now()should approximate the current wall-clock time (Date.now()). On React Native 0.86 (iOS), once the app process has been alive across host/device sleep, that sum drifts behindDate.now()by roughly the total sleep duration —performance.now()appears to advance only while the process/host is awake, whileperformance.timeOriginstays a fixed wall-clock value, so their sum lags.Measured in the JS runtime on a long-lived iOS 27 simulator:
So
timeOrigin + performance.now()was ~7 days in the past, and grows with accumulated sleep.Impact
Any library that reconstructs an absolute timestamp as
timeOrigin + performance.now()gets timestamps in the past. Concretely,@sentry/coretimestamps every span/transaction this way (itscreateUnixTimestampInSecondsFunc), so all performance transactions were stamped ~a week in the past and were silently dropped/hidden by the backend, while errors and sessions (which useDate.now()) were unaffected. This was very hard to diagnose because ingestion accepts the events (HTTP 200) and only drops them later.Steps to reproduce
Expected
performance.timeOrigin + performance.now()stays ≈Date.now()(within a small tolerance), per the HR-Time spec — i.e. eithernow()should include suspended time, ortimeOriginshould be defined consistently with the clock backingnow().Actual
timeOrigin + performance.now()lagsDate.now()by the accumulated sleep time (observed up to ~7 days).Notes / caveats (honest about what I could and couldn't confirm)
ReactCommon/react/nativemodule/webperformance/NativePerformance.cpp(now()→HighResTimeStamp::now(),timeOrigin→unsafeOriginFromUnixTimeStamp()) andreact/timing/primitives.h(backed bystd::chrono::steady_clock) look materially the same between 0.83.4 and 0.86.0. So this could be a libc++/toolchain change insteady_clockbehavior, or environment-specific — maintainer insight very welcome.timeOrigin + now() ≈ Date.now(), drift ~0), whereas RN 0.86.0 did (drift ~7 days). Same@sentry/react-native8.7.0 /@sentry/core10.47.0 in both.Environment