Re: Y2K bug of w3c-libwww-5.2.8/Library/src/HTWWWStr.c:HTParseTime() ?

Hello Noriyuki,

Thanks for your concern.

> Perhaps this is silly question, but...
> Doesn't the HTParseTime() function of latest w3c-libwww (version 5.2.8)
> have Y2K bug?
>
> This function parses a year of RFC850/RFC1036 format which is something
> like "Sunday, 06-Nov-94 08:49:37 GMT" (defined in RFC2616), but
> according piece of the code (line 429 of the HTWWWStr.c) is below:
>           tm.tm_year = strtol(++s, &s, 10);
> Because tm.tm_year is defined as tm.tm_year == (REAL_YEAR - 1900),
> this line seems to have to be changed like follows:
>           tm.tm_year = strtol(++s, &s, 10);
>           if (tm.tm_year < 70)
>               tm.tm_year += 100;

I don't see any problem re: the <70 --> + 100 in libwww, except, perhaps
in the HTNewsLs.c module. I don't know how dates are stored there, in two
or four digits.

I think it wouldn't hurt to add your test, just before we validate the
date.

What do other people think?

> I also think that it is better to fix line 507 of the HTWWWStr.c.
>     if (.... || tm.tm_year >120) {
> 	HTTRACE(CORE_TRACE, "ERROR....... Parsed illegal time: %02d.%02d.%02d %02d:%02d:%02d\n" _
> Because tm.tm_year > 120 is completely valid.

120 is an internal limit becase the time functions where we use tm_year
return (for the moment) a time_t value representing the number of seconds
since Jan 1, 1970. 120 may be there to protect systems that have different
size time_t. The best solution would be to put a system macro there, but
I don't know if it exists. 

In the meantime, it's weird, but won't hurt anyone until 2020 (if libwww
still exists at that time).

If someone else has a different opinion, feel free to give it :)

Regards,

-Jose

Received on Wednesday, 5 January 2000 08:57:23 UTC