fix issue 21148, possible failure of CI when testing nano precision of file time stamps

[ghost]

from man time:

       The software clock, HZ, and jiffies
       The accuracy of various system calls that set timeouts, (e.g.,
       select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2))
       is limited by the resolution of the software clock, a clock
       maintained by the kernel which measures time in jiffies.  The size of
       a jiffy is determined by the value of the kernel constant HZ.

       The value of HZ varies across kernel versions and hardware platforms.
       On i386 the situation is as follows: on kernels up to and including
       2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting
       with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds.
       Since kernel 2.6.13, the HZ value is a kernel configuration parameter
       and can be **100**, 250 (the default) or 1000, yielding a jiffies value
       of, respectively, 0.01, 0.004, or 0.001 seconds.  Since kernel
       2.6.20, a further frequency is available: 300, a number that divides
       evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

       The times(2) system call is a special case.  It reports times with a
       granularity defined by the kernel constant USER_HZ.  User-space
       applications can determine the value of this constant using
       sysconf(_SC_CLK_TCK).

TL;DR

If the kernel setting for the software clock frequency (HZ) is set to 100, we got 10 msec resolution. CIs being on VMs we cant control it's better to assume that the setting can be set to this worst value, so test with a value greater than 10 msecs.

[dlang-bot]

Thanks for your pull request, @NilsLankila!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21148	normal	Semaphoreci: core.exception.AssertError@std/file.d(1929): unittest failure

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7589"

[ghost]

Another valid approach is to drop this test. What is tested here ? a kernel feature ? nano_sleep() ? the filesystem ? This tests nothing of phobos.

[CyberShadow]

What is tested here ?

This is easily answerable using git-blame.

I believe the test is for the part of the timeLastModified implementation which queries non-standard (system-specific) fields of struct stat.

[WalterBright]

I approve with the proviso that your explanation above be added as a comment to that test. Otherwise, that test will remain a mystery, not many people look at git blame.

And thanks for the quick action on this bug, @NilsLankila ! We're slowly bending the test suite into a state where a perfect PR is getting more than a 50% likelihood of passing all the tests.

[WalterBright]

Add the comment.

[ghost]

done, to be clear it is not sure that this will solve the failures, it's just that, according to the doc, a too tight sleep time can be a cause.

Comment added

[ghost]

BTW if someone starts the merge train, dont forget to auto-merge-squash as I've made this PR online.