http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4458/steps/test/logs/stdio

Appears to be new, but also isn't obviously related to any recent checkins that I noticed.

(the Win7 buildbot for trunk isn't in a good place, with regular test_packaging and test_strptime values, too).

Strange, I can't reproduce this on Windows 7 with exactly the same
command line:

python_d  -Wd -E -bb ../lib/test/regrtest.py -uall -rwW -n -r --randseed=8022149

This is rather curious. It looks like the assertion includes a (generous)
fudge factor in case the timing code is inaccurate, but then the actual
time taken is *just* short enough to make it fail.


> (the Win7 buildbot for trunk isn't in a good place, with regular test_packaging and test_strptime values, too).

I can't find any recent failures of test_packaging; do you mean test_imp?

I've opened issue 14113 for the test_strptime failures; it looks like
something's forgetting (or stripping off) a leading zero somewhere.

Re: test_packaging: my mistake, the problem was actually test_package__file__ in test_imp (and Antoine already fixed it - there were some caches that weren't getting cleared properly: #14080)

The last Win7 test run was green, so we may have to write this one up as a weird glitch. I'd say we leave it for a week or so, then close it if it doesn't happen again.

A very similar failure in test_thread:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio

Does Windows still have its once per day/week/whatever time synchronization, or does it use a proper NTP client?
Because this offset is way too large for a broken RTC lock, so it might simply be some process adjusting the clock behind our back (although it's too much for a typical NTP client, at least on Unix).
It could be interesting to replace time.time() by the new time.monotonic().

> It could be interesting to replace time.time()
> by the new time.monotonic().

I changed threading (at least in threading.py) and queue modules to replace time.time() by time.steady() in the issue #14222. Other places in the threading module should be modified to use the new clock.

This failure was not seen recently, let's close this issue.