Hello, On Debian Bo (kernel 2.0.40, gcc 2.7.2.1, libc 5.4.33), wget 1.9.1 and 1.10-alpha3 give a wrong timestamp to downloaded files, when the timestamp is in the hour after the hour following a DST transition.
Example here timezone CET +0100, transition to CEST +0200 on last Sunday of March at 1:00 GMT, if file is between 2:00:00 and 2:59:59 GMT (would be the same on last Sunday of October): | # touch --date "26 Mar 2000 2:30:00 GMT" /var/www/testfile2 | $ vdir --full-time /var/www/testfile2 | -rw-r--r-- 1 root root 0 Sun Mar 26 04:30:00 2000 /var/www/testfile2 | $ wget-1.10-alpha3 --debug http://localhost/testfile2 2>&1 | grep -i "^last-modified:" | Last-modified: Sun, 26 Mar 2000 02:30:00 GMT | $ vdir --full-time /tmp/testfile2 | -rw-r--r-- 1 ag users 0 Sun Mar 26 04:20:39 2000 /tmp/testfile2 | $ TZ=GMT0 vdir --full-time /tmp/testfile2 | -rw-r--r-- 1 ag users 0 Sun Mar 26 02:20:39 2000 /tmp/testfile2 The file correctly served as 2:30 gets downloaded wrongly as 2:20:39 GMT. 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. Due to the way mktime_from_utc() does twice the calculation, the error is compensated all year long, but not during these post transition hours. Setting tm_isdst to -1 (unknown DST) corrects this 9 minutes inaccuracy, but then the complex logic of mktime_from_utc() fails and gives full hour errors. 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. Alain.
