When Queue get and put methods are called with a timeout, they effectively store the end time and might block until that end time is reached.  This breaks if the system time is moved back.  The attached patch breaks out of the wait if it detects the time has been moved back.

I am unsure if this is a sufficient or correct patch, but the functionality is desirable.

When a system moves time backwards, it breaks a host of invariants, not just the one in the queue module.  I would not want some variant of this code used everywhere time differences are computed.  Another thought is that the use case is somewhat exceptional and that the solution (readjusting endtime) isn't necessarily the right thing to do.

I agree that it would be better to fix this everywhere we can.  But unless we start replacing the generic versions of everything that uses a timeout for platform-specific versions (that have guarantees regarding specified timeouts and notifications), about all we can really do is to patch each item as we go along.  I suppose a good first step would be to write a generic "wait for" function that would sit in threading, _Condition.wait() is a good start.  From there, one could write platform variants (Windows could use WaitForSingleObject, etc.) that don't change the end time, calling them on a platform if they exist.

I was recommending against "fixing" this everywhere.  See related comments on pathc #1607149: Condition.wait timeout fails on clock change.

Recommend closing this patch.  The problem is not the responsibility of every client accessing time() or sleep().  The clients do not have enough information to reliably detect changes and to know how much the time changed.  Even if those are known, it is not clear that adjusting the timeout is the always right thing to do.

Also, this "problem" is somewhat obscure.  Lowering the priority to 1 and recommending that the patch (and all like it) be rejected.

Rejecting this patch for the same reason #1607149 was rejected.