Currently time.Now is using a low precision time, which makes a lot of duration measurements imprecise. Currently there seems to be only QueryPerformanceCounter, which provides sub-microsecond precision for measurements. This lead to replacing time measurement workarounds in benchmarks (#31160).

It's clear that using in benchmarking context QPC is fine, because that's what https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps recommends. However it's less clear whether there are problems with measuring longer durations (e.g. several years) or whether there are peculiarities with call overhead.

To summarize, the open questions that would need answering before it's reasonable to change time.Now behavior are:

1. What's the reasoning QueryPerformanceCounter wasn't used from the start?
   • As far as I understand, there were older Windows versions and WINE that needed more handholding and using QPC introduced problems. If that's the case, then are these problems still present in versions supported by Go.
2. Are there problems measuring long durations with QPC, e.g. 2 years. (runtime: windows system clock resolution issue #8687 (comment) does mention it's not stable long-term)
3. Are there problems with QPC taking significantly longer on some systems (e.g. 1000ns)? e.g. maybe some system using high resolution timer. I don't know there are any such problems, but then again the documentation doesn't seem to provide guarantees.
   • The call overhead to QPC seems to be ~20ns-40ns on my system, compared to the current time.Now 4.5ns.
4. Are there any problems with regards to system sleeping and waking?

If this is implemented then the change in https://go-review.googlesource.com/c/go/+/557315 can be reverted.

Note, this would be only for the monotonic time measurements.

Related issue for benchmarking:

• testing: benchmark is using low resolution time on Windows #31160