A hardware timer is a monotonic clock, and at least one is built into any computer. With the advent of GPS spoofing, you can't really rely on GPS, either.

Can't wait for the miniaturisation of atomic clocks. They're quite already small but once they're 'so cheap they're on every SoC' a lot of ills of 'cheap' (as in not GC or AWS or Facebook) real-time distributed systems builders might go away.

"not increasing" is a permissible interpretation of monotonic though. The clock should never go backward, but not increasing for a brief period is acceptable. It does mean you can't use it for 100% high-precision work, but at least you'll not be surprised by a negative result.

But having a clock not progressing might break some wait- and timeout-based designs and you spend a lot of time understanding the strange phenomenon in a large fleet.

That PR is about buggy or niche systems. VMs lying about their clocks, CPUs with faulty firmware revisions, kernel bugs. Rust is just going the extra mile to uphold its guarantee even when the OS fails to do its job. It would have been legitimate to just say that in the face of broken systems you get broken behavior, GIGO, but it's difficult to convey that and most users aren't even aware that their systems are broken so it provided better user experience to paper over the bug rather than surfacing it.

On most systems CLOCK_MONOTONIC actually is monotonic. It's not necessarily steady or providing SI seconds, but its monotonic.

You'll need stuff like GPS if you want a monotonic, steady clock synchronized with other clocks.