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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> "Mark D. Baushke" <mdb@cvshome.org> 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.

Yes.

> 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.

Even worse, most hosts have a maximum of 31-bit postive values for
time_t which means that any date past 'Jan 19 2038 03:14:07 +0000'
would be the maximum...

> 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.

Agreed. I have done so.

> > 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.

Thank you.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBkrcR3x41pRYZE/gRAkqmAJ96VUubKpbc8LhrGoNeQUG0bOYu/wCff3LY
ea08LHVfwrIgQjSkLndP5bI=
=Gk4F
-----END PGP SIGNATURE-----