ReactNative: avoid representing unix nanoTime as a double

[lemnik]

Goal

Avoid precision loss when dealing with the unix timestamp in ReactNative.

Design

Rework the ReactNative Clock.toUnixTimestampNanoseconds to use two number values representing 32bit integers to form two halves of an int64 and convert directly from the format into a string.

Whenever we transfer a timestamp to or from the native layer, the code now uses a string timestamp in the wire format to avoid any loss of precision.

The iOS code also now uses an improved conversion to go from a string representing an int64 to an NSNumber representing the standard iOS unix timestamp and then to an NSDate for compatibility with bugsnag-cocoa-performance.

Testing

Updated the unit tests for the new format, along with more reliable runs of the existing end2end tests.

[github-actions]

Browser bundle size

NPM build

	Package
Before	234.66 kB
After	234.57 kB
±	-87 bytes 🎉

CDN build

	Unminified	Minfied	Minified + gzipped
Before	119.04 kB	45.94 kB	13.25 kB
After	119.04 kB	45.95 kB	13.25 kB
±	+1 bytes ⚠️	+7 bytes ⚠️	+2 bytes ⚠️

Code coverage

Ok	File (✨=New File)	Lines	Branches	Functions	Statements
🔴	/home/runner/work/bugsnag-js-performance/bugsnag-js-performance/packages/core/lib/clock.ts	83.33% (-16.67%)	100% (+0%)	50% (-50%)	80% (-10%)
🔴	/home/runner/work/bugsnag-js-performance/bugsnag-js-performance/packages/platforms/browser/lib/clock.ts	92.59% (+0.29%)	62.5% (+0%)	100% (+0%)	92.68% (-1.91%)
🔴	/home/runner/work/bugsnag-js-performance/bugsnag-js-performance/packages/platforms/react-native/lib/clock.ts	93.87% (-6.13%)	73.91% (-26.09%)	100% (+0%)	94.54% (-5.46%)

Total:

Lines	Branches	Functions	Statements
84.79%(+0.21%)	62.59%(+0.33%)	75.28%(+0.03%)	81.74%(+0.26%)

Generated against 9f952e3 on 6 August 2025 at 08:05:04 UTC

The base branch was changed.

[gingerbenw]

Can't quite get my head around some of the maths in lib/clock.ts but the logic is good and I'm happy that the tests cover it