> Does the same apply for time.monotonic? I would argue that the 
> difference in behavior between Linux/macOS and Windows is 
> unreasonable; given that time.monotonic exists for measuring time 
> intervals

For time.monotonic in Windows, Python could switch to using QueryUnbiasedInterruptTime [1], which excludes periods in which the system is suspended or hibernated. In Windows 10, QueryUnbiasedInterruptTimePrecise [2] can be used, which directly reads the counter in the hardware timer instead of the value at the last timer interrupt.

For time.time in Windows, Python 3.10 should switch to using GetSystemTimePreciseAsFileTime [3] instead of GetSystemTimeAsFileTime. 

For time.perf_counter in Windows, QueryPerformanceCounter remains the best option since it uses the invariant TSC in the CPU if available.

---

Note that, unlike GetTickCount64, the resolution for QueryUnbiasedInterruptTime isn't lpTimeIncrement from GetSystemTimeAdjustment [4]. lpTimeIncrement is the initial default and upper bound for the interrupt period, which can be adjusted down with timeBeginPeriod or the undocumented system call NtSetTimerResolution. The former can lower the interrupt period from the default of about 10-16 ms (usually 15.625 ms, i.e. 64 interrupts/second) down to about 1 ms, while NtSetTimerResolution goes down to about 0.5 ms. It's not free, however, else it would be the default setting. More frequent timer interrupts can decrease system performance and increase power consumption.

---

[1] https://docs.microsoft.com/en-us/windows/win32/api/realtimeapiset/nf-realtimeapiset-queryunbiasedinterrupttime

[2] https://docs.microsoft.com/en-us/windows/win32/api/realtimeapiset/nf-realtimeapiset-queryunbiasedinterrupttimeprecise

[3] https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime

[4] https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimeadjustment