I think the minimum bound for dt could stand to be relaxed very slightly, here's some results from my 64-bit Win7 box running 32-bit Python:

3.4.0b1 (default:eae6966d9734+, Dec 21 2013, 15:47:14) [MSC v.1600 32 bit (Intel)]
sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
Running:
import time
import sys
print(sys.version)
print(sys.getwindowsversion())

with open(__file__) as file:
    print('Running:')
    print(file.read())

for i in range(10):
    # copied from test_monotonic, with regular assert and added prints
    t1 = time.monotonic()
    time.sleep(0.5)
    t2 = time.monotonic()
    dt = t2 - t1
    assert t2 > t1
    print(i, t1, t2, dt, sep='\t')
    print('  assertion', 'passed' if 0.5 <= dt <= 1.0 else 'failed')

0	243323.54200000002	243324.041	0.4989999999816064
  assertion failed
1	243324.041	243324.54	0.4990000000107102
  assertion failed
2	243324.54	243325.03900000002	0.4990000000107102
  assertion failed
3	243325.03900000002	243325.53900000002	0.5
  assertion passed
4	243325.53900000002	243326.038	0.4989999999816064
  assertion failed
5	243326.038	243326.537	0.4990000000107102
  assertion failed
6	243326.537	243327.036	0.4989999999816064
  assertion failed
7	243327.036	243327.535	0.4990000000107102
  assertion failed
8	243327.535	243328.035	0.5
  assertion passed
9	243328.035	243328.534	0.4990000000107102
  assertion failed


I suspect there's some rounding going on somewhere, making dt usually about 0.499, not 0.5.  Relaxing the condition to '0.498 < dt < 1.0' should be adequate, since I don't think a thousandth of a second only part of the time is enough to say there's a behavior issue.

I haven't seen this fail on any buildbots, but I suspect most of them are just loaded a bit heavier than my laptop is when I see this.