I am not excited by tests on clocks. In the past, I had to remove such tests which were too fragile.

Would it make sense to add a test on time.get_clock_info()? Maybe a test specific to macOS?

@vstinner I am usually not excited by clock tests either. However, I was looking for you to investigate why process_time has been broken in 3.7 :) Also, I would think that this problem might be seen on other platform/versions that lack clock_gettime.

Good call, @vstinner! It looks like the test case as it stands is too fragile: it failed on the Azure Pipeline win64.

FAIL: test_perf_counter_vs_process_time (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\1\s\lib\test\test_time.py", line 512, in test_perf_counter_vs_process_time
    self.assertAlmostEqual(processtime, perfcounter, places=2)
AssertionError: 0.140625 != 0.15217669999992722 within 2 places (0.011551699999927223 difference)

Well, it should still be useful in figuring out what the problem is. We can decide later whether to make it more robust and add to the repo.

Yeah, please don't add such test which rely too much on clock resolution/accuracy. These tests fail often in the past, it's very painful to fix them. For example, I modified some tests to tolerate a delta of 1 second on a duration which should be 20 ms... Such test doesn't make an sense anymore...

I still think it would be better to have a test for this case since the problem embarrassingly went undetected for quite some time. But I'll let some one else deal with it if they care to.