u64 can't be represented as a primitive in Java or TypeScript (and for the latter, Neon doesn't support bigint yet). However, for timestamps represented as milliseconds, the integer-safe range of float64 still covers more than 285,000 years, so it's reasonably safe to use TypeScript's 'number' or Java's 'long' to represent these ostensibly-64-bit values. Indicate this with a new Timestamp wrapper type in the bridge layer.
In theory we could push this new Timestamp type down to the libsignal-protocol crate. However, the protocol itself doesn't impose any restrictions on the timestamp fields, so I figured it was best to put it at the bridge layer, to indicate that it's about how Signal specifically uses these fields.
This commit paves the way for being stricter about other u64 values that might want to use the full 64-bit space.
u64 can't be represented as a primitive in Java or TypeScript (and for the latter, Neon doesn't support bigint yet). However, for timestamps represented as milliseconds, the integer-safe range of float64 still covers more than 285,000 years, so it's reasonably safe to use TypeScript's 'number' or Java's 'long' to represent these ostensibly-64-bit values. Indicate this with a new Timestamp wrapper type in the bridge layer.
In theory we could push this new Timestamp type down to the libsignal-protocol crate. However, the protocol itself doesn't impose any restrictions on the timestamp fields, so I figured it was best to put it at the bridge layer, to indicate that it's about how Signal specifically uses these fields.
This commit paves the way for being stricter about other u64 values that might want to use the full 64-bit space.