You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version: v0.23.4 OS: Arch Linux x86_64 Shell: bash 5.3.3(1)-release Terminal: xfce4-terminal 1.1.5
Not sure if the following also matters, just adding in case: Time zone: Europe/Berlin LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8
Steps to reproduce:
touch -d 2010-12-14 test_2010-12-14
touch -d 2014-05-20 test_2014-05-20
ls -l test*
-rw-r----- 1 markus markus 0 14. Dez 2010 test_2010-12-14
-rw-r----- 1 markus markus 0 20. Mai 2014 test_2014-05-20
eza -l test*
.rw-r----- 0 markus 14 Dez 2010 test_2010-12-14
.rw-r----- 0 markus 19 Mai 2014 test_2014-05-20
These are my observations from the terminal output shown above:
"original ls" shows file dates as expected.
Therefore I don't think it's caused by erroneous TZDATA or any environmental factor.
eza shows date off by one day for the newer one of the test files.
Therefore I don't think it's like "all files older than x are affected".
Version: v0.23.4
OS: Arch Linux x86_64
Shell: bash 5.3.3(1)-release
Terminal: xfce4-terminal 1.1.5
Not sure if the following also matters, just adding in case:
Time zone: Europe/Berlin
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
Steps to reproduce:
These are my observations from the terminal output shown above:
Therefore I don't think it's caused by erroneous TZDATA or any environmental factor.
Therefore I don't think it's like "all files older than x are affected".
Therefore I don't think it's a duplicate of bug: no time information for files before UNIX epoch #1668, although I'm not sure about this.
I've tested it on ext4 and tmpfs.