Description
tests/unit/test_time_util.py::TimeUtilTest::test_times_from_uuid1 is flaky on Windows CI. It compares time.time() against a UUID1-derived timestamp with a ±0.01s tolerance, but Windows timer resolution and CI runner load can cause drift exceeding that threshold.
Failure example
From https://github.com/scylladb/python-driver/actions/runs/24655416197/job/72087636196?pr=651 (Windows wheel build, cp310-win32):
FAILED tests/unit/test_time_util.py::TimeUtilTest::test_times_from_uuid1
assert 1776672729.6936648 == 1776672729.7092667 ± 0.01
comparison failed
Obtained: 1776672729.6936648
Expected: 1776672729.7092667 ± 0.01
The actual drift was ~15.6ms — just over the 10ms tolerance.
Suggested fix
Increase the tolerance to 100ms (±0.1s), or restructure the test to avoid comparing wall-clock timestamps across a UUID1 generation boundary. Windows time.time() resolution is typically 15.6ms (one tick), so 10ms tolerance is inherently unreliable there.
Context
Observed while running CI for PR #651 (load balancing policy optimizations). The failure is unrelated to that PR — all 672 other tests passed.
Description
tests/unit/test_time_util.py::TimeUtilTest::test_times_from_uuid1is flaky on Windows CI. It comparestime.time()against a UUID1-derived timestamp with a ±0.01s tolerance, but Windows timer resolution and CI runner load can cause drift exceeding that threshold.Failure example
From https://github.com/scylladb/python-driver/actions/runs/24655416197/job/72087636196?pr=651 (Windows wheel build, cp310-win32):
The actual drift was ~15.6ms — just over the 10ms tolerance.
Suggested fix
Increase the tolerance to 100ms (±0.1s), or restructure the test to avoid comparing wall-clock timestamps across a UUID1 generation boundary. Windows
time.time()resolution is typically 15.6ms (one tick), so 10ms tolerance is inherently unreliable there.Context
Observed while running CI for PR #651 (load balancing policy optimizations). The failure is unrelated to that PR — all 672 other tests passed.