bug#29265: gzip-1.8.41 test results: timestamp

[Bruno Haible]

Paul Eggert wrote:
> Thanks. I am puzzled by the failures. For example:
> 
> > + touch -t 190101010000 in
> > + returns_ 2 gzip in
> > + fail=1
> 
> Here, 'touch' succeeded, but gzip did not diagnose the negative timestamp. Do 
> other programs report that the timestamp is 1901? For example, what is the 
> output of this?
> 
>    export TZ=UTC0
>    touch -t 190101010000 in
>    ls -l in
>
> Likewise for the timestamps 203801190314.08 and 210602070628.15, both of 
> which 
> are out of range for gzip but gzip did not diagnose it.

OpenBSD/i386:
NetBSD/sparc:

$ export TZ=UTC0
$ touch -t 190101010000 in
$ ls -l in
-rw-r--r--  1 bruno  bruno  0 Feb  6  2037 in
$ ls -lT in
-rw-r--r--  1 bruno  bruno  0 Feb  6  06:28:16 2037 in
$ touch -t 203801190314.08 in2
$ ls -l in2
-rw-r--r--  1 bruno  bruno  0 Dec 13  1901 in2
$ ls -lT in2
-rw-r--r--  1 bruno  bruno  0 Dec 13 20:45:52 1901 in2
$ touch -t 210602070628.15 in3
$ ls -l in3
-rw-r--r--  1 bruno  bruno  0 Dec 31  1969 in3
$ ls -lT in3
-rw-r--r--  1 bruno  bruno  0 Dec 31 23:59:59 in3

IRIX 6.5 with n32:

$ export TZ=UTC0
$ touch -t 190101010000 in
Bad date conversion
$ ls -l in
Cannot access in: No such file or directory
$ touch -t 203801190314.08 in2
$ ls -l in2
-rw-r--r--    1 bruno    bruno          0 Dec 13  1901 in2
$ touch -t 210602070628.15 in3
Bad date conversion
$ ls -l in3
Cannot access in3: No such file or directory

Regarding OpenBSD, I've just reported this to the OpenBSD people:
https://marc.info/?l=openbsd-bugs&r=1&b=201711&w=2

> I installed the attached patch to tests/timestamp, partly in response to your 
> earlier advice that we can't trust 'touch' to have the same time_t range as 
> 'gzip', and partly in response to the abovementioned failures. This patch 
> uses 
> 'ls' to check the timestamp that 'touch' succeeded on.

This patch fixes the test failure on all three platforms.

> While testing this, I discovered that on Solaris 10 and 11, file timestamps 
> before the Epoch result in tv_nsec < 0! This bug is new to me. I plan to look 
> into that bug separately. I expect that the best way to work around it is to 
> add 
> Gnulib code to fix the bogus timestamps.

I expect that Solaris will not be the only platform with this bug...

Bruno