GNU bug report logs - #75682
ls -l sometimes shows a year in place of the hour and minute

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Kasia <xo.okasia <at> proton.me>
Cc: 75682 <at> debbugs.gnu.org
Subject: bug#75682: ls -l sometimes shows a year in place of the hour and minute
Date: Sat, 15 Feb 2025 21:54:06 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.