Alain Guibert <[EMAIL PROTECTED]> writes:
> No such problem with Woody and Glibc. This problem seems to be half
> Wget half libc 5.4.33. In src/http.c:mktime_from_utc() and
> http_atotm(), Wget manipulates tm structs forcing tm_isdst to
> 0. Which is false 7 monthes a year, and hurts libc mktime() function
> giving garbage result.
I was lead to believe that it is quite reasonable to set tm_isdst to
zero before calling mktime. In fact, the logic in mktime_from_utc,
along with setting tm_isdst to zero, was explicitly written to support
discontinuities at DST transition points -- see Roger Beeman's
changelog entry from 2001-04-25.
> The libc5 problem is that, given a tm with forced wrong tm_isdst,
> mktime() garbles the tm content and returns a consistent but wrong
> time_t. Example given a tm containing {0, 0, 0, 1, 7, 105, 0, 0, 0}
> (1 Aug 2005 0:00), mktime() gives {39, 50, 0, 1, 7, 105, 1, 212, 1}
> (1 Aug 2005 0:50:39 CEST) and returns 1122850239.
Fortunately there is an easy solution for this: simply #undef
HAVE_MKTIME in config.h. This will enable the use of Wget's mktime
replacement that comes from glibc 2 and does not have the bug. (The
same applies to manually undefining HAVE_STRPTIME and using the
strptime replacement.)
It would be nice if configure checked for this, but I'm not sure how
to reliably check for glibc versions from configure. Since libc 5 is
so rare these days, I don't feel like devoting too much time to this.
Patches will be accepted, though.
Thanks for the report.
