Can `Instant`s be `NonZeroU64`?

[metrics-rs]

Can `Instant`s be `NonZeroU64`?

[hawkw]

Of course, if it's possible for quanta to ever generate Instants with the u64 value 0, this won't work, so we'd need to know for sure that this is the case. Otherwise, we'll need to find an alternative solution for my use case.

[tobz]

Thinking through this one a little bit, and putting my thoughts down in this issue...

I think, practically speaking, there is an infinitesimally small chance of generating an Instant whose raw value is 0. While our reference time anchor may initially be zero -- unlikely, very unlikely, but technically possible -- and our TSC scaling factor could end up scaling a raw TSC read to zero... it's just... super unlikely. That said, it's technically possible: timespec in libc uses signed integers for both the second and nanosecond components. We might end up somewhere before zero, with the TSC addition bringing it up to zero.

There's also the technically-possible-but-highly-unlikely issue of integer overflow/wraparound as we scale up the raw TSC value and then add it to the reference time anchor, bringing it inline with the output you'd get from clock_gettime(CLOCK_MONOTONIC) directly.

While we could always construct an Instant such that we bitwise-AND the value with one, to ensure it's non-zero, that's an extra instruction for every single time we build an Instant, which is annoying. Maybe not practically meaningful, performance-wise, certainly compared to the other heavy-handed stuff that std::time is doing... but still not great.

[tobz]

The other thing is that doing so would introduce a 1ns forward jump about half of the time, which isn't terrible in terms of accuracy, but it might make monotonicity invariants harder to achieve. Gotta think through that one...

[tobz]

Just to close the mental loop around the bitwise-AND idea for my own sake: I think this would work.

Since we're only ever adding to the value, we won't be changing the numbers such that they warp backwards in time, which upholds the monotonicity invariant between two values of Instant. At worst, we may end up with two measurements -- T0 and T1 -- that, when uncorrected, are 1 nanosecond apart. If T0 was even, we would increment it by 1ns, which would make it equal to T1.

I'll whip up a simple PR to benchmark the change.