Re: [Bug-gnulib] Re: GNULIB mktime.c compilation failure on UNICOS 9.0 Cray Y-MP EL

[Paul Eggert]

"Mark D. Baushke" <address@hidden> writes:

> The getdate test program has one problem....
> I am guessing this is because all integral numbers on UNICOS are 8
> bytes.

That test case has three bugs.  First, the comment

# Feb. 29, 2096 8 years
#   8 years from this date is _not_ a leap year, so Feb. 29th does not exist.

is incorrect, since 2104 is a leap year.

Second, on this example getdate fails on 32-bit hosts because 2104
isn't representable, but as you noted it will succeed on 64-bit hosts,
so the test case isn't portable.

Third, the underlying motivation for the test case is incorrect.  For
date arithmetic getdate defers to mktime, so examples like "Feb. 29,
2004 +1 year" succeed, and return values like 2005-03-01.  I suppose
that one could argue that this is the "wrong" answer, but one can just
as easily argue that it's a correct answer, and that it's better to
return an answer rather than fail.  Here's another argument: the
string "now +1 year" should always succeed, but if the current date is
Feb. 29 it would fail if getdate took the persnickety interpretation.

The simplest fix is to remove that particular test case.


> Please commit your change to GNULIB.

I've submitted a bug report to glibc here:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=541

When the fix is committed it should propagate to gnulib.