The existing tests

I've manually verified the new values:

>>> time.get_clock_info("process_time")
namespace(implementation='GetProcessTimes()', monotonic=True, adjustable=False, resolution=0.015625)
>>> time.get_clock_info("thread_time")
namespace(implementation='GetThreadTimes()', monotonic=True, adjustable=False, resolution=0.015625)

cc @vstinner since #82040 (comment)

Patches are welcome to enhance time.get_clock_info() :-)

This isn't the way, I'm afraid. The specified resolution is all we know, and undocumented behaviours like the resolution a system is actually going to write into the data structures isn't something we should be hard coding and relying on.

These functions should really only be used for reporting, not for decision making. If tests want to use them for decision making, then they also need a control to verify that they're going to work as intended (e.g. run a known amount of work and make sure that it registers in these functions).

At worst, we should try and read the current interval, rather than hard-coding the worst case scenario. But even that's risky, as it can change while the system is running (not a great idea, because programs do rely on it, and they can get into trouble as it changes, but we shouldn't be encouraging people to write code like tht).

Ah, ok, I see. Even the PEP (https://peps.python.org/pep-0418/#process-time) lists

These functions should really only be used for reporting, not for decision making

Seems to happen even in the stdlib

Maybe just a documentation issue?

Converting to draft tagging as DO-NOT-MERGE ...

The PEP isn't the documentation of the OS. If you can find a reference on learn.microsoft.com that states the resolution of that specific function, then we can lock it in. But you won't, because the resolution of the actual timer is deliberately left unspecified. (You'll find examples showing that it's typically around 15ms and adjustable down for some benefit in some situations, but no guarantees.)

A lot of code in the stdlib, and especially its test suite, is "best effort" to make something work. It's not necessarily a robust example of the best way to implement something. Trust the upstream docs, just like we expect people to trust ours 😉

Oh yes, I frequently read the MSDN :)

With

Maybe just a documentation issue?

I meant we could add some hints about that to https://docs.python.org/3/library/time.html#time.get_clock_info

resolution: The resolution of the clock in seconds (float)

Specifically something like

These functions should really only be used for reporting, not for decision making

Clarifying documentation is always fine, provided it doesn't specify us into a corner. Something along the lines of "this is a theoretical resolution, and not necessarily the rate at which the values are updated" and "these functions should not be treated as high-precision timers on most operating systems" would be fine.