1. 32
  1.  

  2. 6

    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.

    1. 5

      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

      1. 3

        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)

    2. 3

      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):

      https://github.com/python/cpython/blob/f660567/Python/pytime.c#L7

      As with other PRs, they’ll probably need to switch to: https://developer.apple.com/documentation/kernel/1646199-mach_continuous_time

      Toward that: https://bugs.python.org/issue42107