Rust’s monotonic time interface defends against this somewhat, seemingly for good reason:
// We're seeing panics across various platforms where consecutive calls
// to `Instant::now`, such as via the `elapsed` function, are panicking
// as they're going backwards. Placed here is a last-ditch effort to try
// to fix things up. We keep a global "latest now" instance which is
// returned instead of what the OS says if the OS goes backwards.
Not that the current time seeming to freeze for minutes or hours seems particularly great either.
But you left out my favorite part of that code comment. I chuckle whenever I stumble upon this file…
// And here we come upon a sad state of affairs.
The resigned sigh of a programmer having to hack a fix for broken OS code. :D
yeah, IIRC we saw this in production for the dropbox sync client on macOS and added our own mitigation. interestingly the rust stdlib includes macOS on its Instant::actually_monotonic list…
(former dropboxer who worked on the sync engine)
It looks like this should be an issue for Python, as time.monotonic() appears to be backed by mach_absolute_time() (linking to the head of the 3.9 branch):
As with other PRs, they’ll probably need to switch to:
Toward that: https://bugs.python.org/issue42107