Clock resolution test failures on WSL with Nix

[AlexKnauth]

I'm getting these clock resolution test failures when installing time-compat on my Windows machine with WSL and Nix:

    resolution
      getCurrentTime:                                                             FAIL (0.14s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.000000001s
         but got: 0.0000001s
      taiClock:                                                                   FAIL (0.15s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.000000001s
         but got: 0.0000001s

2 out of 859 tests failed (0.89s)
Test suite main: FAIL
Test suite logged to: dist/test/time-compat-1.9.5-main.log
Test suite instances: RUNNING...
Test suite instances: PASS
Test suite logged to: dist/test/time-compat-1.9.5-instances.log
1 of 2 test suites (1 of 2 test cases) passed.

I got these while attempting to install nix-thunk on WSL, see: obsidiansystems/nix-thunk#23

The failure is coming from assertEqual "resolution" res $ gcdAll times here:

time-compat/test/main/Test/Clock/Resolution.hs

Line 57 in 3fe7a16

assertEqual "resolution" res $ gcdAll times

[rickynils]

I see the same error when building on aarch64-linux (on https://nixbuild.net):

    resolution
      getCurrentTime:                                                             FAIL (0.13s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.000000001s
         but got: 0.00000004s
        Use -p '/getCurrentTime/' to rerun this test only.
      taiClock:                                                                   FAIL (0.14s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.000000001s
         but got: 0.00000004s
        Use -p '/taiClock/' to rerun this test only.

[phadej]

getTime_resolution is only shimmed for relatively old time versions. Have either of you tried to run time tests?

[matoro]

I am getting a similar but opposite error on riscv64-linux; where the expected resolution is less precise than the actual resolution:

    resolution
      getCurrentTime:                                                             FAIL (1.21s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/getCurrentTime/' to rerun this test only.
      taiClock:                                                                   FAIL (1.22s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/taiClock/' to rerun this test only.

[phadej]

@matoro same question applies to you:

getTime_resolution is only shimmed for relatively old time versions. Have you tried to run time tests?

[zeldin]

I have the same result as matoro when running tests on riscv64-linux:

    resolution
      getCurrentTime:                                                             FAIL (1.21s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/getCurrentTime/' to rerun this test only.
      taiClock:                                                                   FAIL (1.25s)
        test/main/Test/Clock/Resolution.hs:57:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/taiClock/' to rerun this test only.

I also tried running tests on https://github.com/haskell/time, both version 1.9.3 (the one bundled with ghc 9.0.2) and version 1.12.2 (the current one). 1.12.2 passed all its tests, but 1.9.3 did give familiar test fails:

  LocalTime
      getCurrentTime:                                                             FAIL (1.20s)
        test/main/Test/Clock/Resolution.hs:43:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/getCurrentTime/' to rerun this test only.
      taiClock:                                                                   FAIL (3.92s)
        test/main/Test/Clock/Resolution.hs:43:
        resolution
        expected: 0.004s
         but got: 0.000000001s
        Use -p '/taiClock/' to rerun this test only.

[phadej]

       expected: 0.004s
         but got: 0.000000001s

is ok, getting smaller resolution than expected (i.e. clock is more precise that it says).
The time test-suite has done that recently: haskell/time@6516a35

Patch to fix test-suite (from == to <=) is welcome.

(As I don't have a system where it fails, it's harder for me to get it right).

---

In original reports

        expected: 0.000000001s
         but got: 0.00000004s

getting larger resolutions that what is actually reported is bad :( but they should test with time test-suite first.

[NorfairKing]

I'm seeing this as well https://staging.nix-ci.com/account/repo/bf96246f-fadf-4cff-88c5-c48004c80e00/suite/e26d82b7-ed80-4337-a1de-15e9c293ad69/run/2fd40868-8ef0-4397-ad03-dc0b6794d3e4

[phadej]

@NorfairKing same question as to all others. Have you tried time test-suite. The implementation is from time, as n the test is also copied from time.

So if it fails, it's very likely it's an upstream time issue. (Except if something is changed, but afaik from https://github.com/haskell/time/blob/618b690e3b80bbafcb3889decf7b3d22a7a51980/test/main/Test/Clock/Resolution.hs the test is the same).