Reported resolution of `time.process_time` and `time.thread_time` is wrong on Windows

[chris-eibl]

Bug report

Bug description:

>>> import time
>>> time.get_clock_info("process_time")
namespace(implementation='GetProcessTimes()', monotonic=True, adjustable=False, resolution=1e-07)
>>> time.get_clock_info("thread_time")
namespace(implementation='GetThreadTimes()', monotonic=True, adjustable=False, resolution=1e-07)

The reported resolution=1e-07 is way off. According to @eryksun in #82040 (comment)

Don't read too much into the clock info here:
Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). But the kernel schedules threads based on a timer that ticks every 15.625 ms by default. It can be lowered to about 0.5 ms, but this degrades battery life.

This has also caused problems in test_int.test_denial_of_service, see #114911 (comment).

I suggest to report 15.625 ms, since this is the upper limit.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• GH-135304: Reported resolution of time.process_time and time.thread_time is wrong on Windows #135305

[vstinner]

But the kernel schedules threads based on a timer that ticks every 15.625 ms by default. It can be lowered to about 0.5 ms, but this degrades battery life.

Is there an API to query the clock resolution?

[zooba]

Only this undocumented one, which seems pretty unlikely to change, given the amount of "optimisation" software that uses it already, but I don't think we want to put Python into that category.

I'm yet to see a problem critical enough to require needing to know an exact value.

FWIW, the concept of increasing the timer resolution is meant for temporary, per-process use. It's not meant to be a system-wide setting, it just happens to have the effect that the system timer has to match the highest resolution request.