On 2025-02-15 17:54, Kasia via GNU coreutils Bug Reports wrote:
"Linux 6.1.0-29-amd64"
So this cannot be the multigrain timestamps in Linux 6.13, released
January 20 and so new that even I'm not running it yet.
I thought that this was a GNU coreutils bug because the same test using
`busybox ls -l` was always giving the hour and time.
This is because busybox ls, contrary to POSIX, acts as though files that
are in fact dated up to 15 minutes in the future were last modified in
the past. You can verify the busybox bug as follows:
$ date
Sat Feb 15 21:45:10 PST 2025
$ touch -d'now + 14 minutes' futurefile
$ ls -l futurefile
-rw-rw-r-- 1 eggert eggert 0 Feb 15 2025 futurefile
$ busybox ls -l futurefile
-rw-rw-r-- 1 eggert eggert 0 Feb 15 21:59 futurefile
$ date
Sat Feb 15 21:45:34 PST 2025
Here the busybox behavior is clearly wrong. (Maybe file a bug report to
the busybox people?)
"ls (GNU coreutils) 9.1"
So this is quite likely the bug in Linux+glibc that Bruno mentioned,
where the clock appears to jump backwards by up to 10 ms[1]. Although
recent versions of coreutils have a workaround, coreutils 9.1 lacks the
workaround.
Please try upgrading to coreutils 9.6 to fix the 'ls' issue, and be
aware that other programs may still misbehave on your system since the
actual bug is below the coreutils level.
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=30200
