Bruno Haible wrote:

> Since Paul asked about more details on this one in
> https://lists.gnu.org/archive/html/bug-gzip/2017-11/msg00005.html
> here are more details (on OpenBSD/i386):
> 
> $ make check TESTS=timestamp VERBOSE=yes > timestamp.x 2>&1

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.

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. If the check fails, we 
don't bother to try 'gzip' on the same timestamp since the files' timestamp is 
dicey. Although this weakens the gzip testing, that's probably better than all 
these false alarms. This should fix some of the timestamp failures that you have 
reported.

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.