Bruno Haible wrote:
$ export TZ=UTC0
$ rm -f in in.gz; touch -t 190101010000 in; ../../gzip in; echo $?
0
$ rm -f in in.gz; touch -t 190101010000 in; ls -l --full-time in
-rw-rw-r-- 1 bruno bruno 0 1901-01-01 00:00:00.000000000 +0000 in
This is due to a bug in the Linux kernel, when it emulates 32-bit Linux atop a
64-bit kernel. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1419736
I see that Assaf reported the same bug against gzip here:
https://bugs.gnu.org/25636#8
I don't see an easy way of working around the bug in gzip proper. It will become
a bigger deal when the year 2038 rolls around....
I suppose we could skip the test when running in 32-bit mode atop Linux x86-64,
though that sort of misses the point of doing the test.
