[issue1508864] threading.Timer/timeouts break on change of win32 local time

STINNER Victor added the comment: As Antoine wrote, Condition.wait() was rewritten in Python 3.2 to implement timeout using the native OS "acquire a lock with a timeout" function. So the initial concern is already fixed. This change is huge, we are not going to backport new lock timeouts in Py

[issue1508864] threading.Timer/timeouts break on change of win32 local time

Mark Lawrence added the comment: PEP 418 states "time.monotonic(): timeout and scheduling, not affected by system clock updates" and has also deprecated time.clock() so I believe this can be closed as "out of date". -- nosy: +BreamoreBoy ___ Python

[issue1508864] threading.Timer/timeouts break on change of win32 local time

STINNER Victor added the comment: > threading.py imports time.time as _time. threading is now using a monotonic clock: see the issue #14222 and the PEP 418. -- ___ Python tracker ___

[issue1508864] threading.Timer/timeouts break on change of win32 local time

Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue1508864] threading.Timer/timeouts break on change of win32 local time

Antoine Pitrou added the comment: The wait loop in Condition.wait() has disappeared under 3.2 (we use builtin lock-with-timeout primitives instead). Overall, I don't think this issue is very important. Changing the system time *backwards* can cause all kinds of issues in daemons and other lon

[issue1508864] threading.Timer/timeouts break on change of win32 local time

Changes by Brian Curtin : -- components: +Windows versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker ___ _

[issue1508864] threading.Timer/timeouts break on change of win32 local time

Changes by Daniel Diniz : -- keywords: +patch stage: -> test needed type: -> behavior versions: +Python 2.6, Python 3.0 ___ Python tracker ___ ___