Hello Roger, On Thursday, May 19, 2005 at 8:09:51 AM -0700, Roger L. Beeman wrote:
> I have been trying to follow this thread, but have not yet devoted > enough time to fully understand the issues, so I would very much > appreciate the summary. The <[EMAIL PROTECTED]> address is no longer > valid, but I am subscribed to the list. Edward Sabol was an integral > contributer to the current version and I would ask that he also lend > a hand in revisiting this issue. Let's try the summary. I see 3 points: (1) Libc 5.4.33 own mktime() produces wrong by some minutes results for all summer dates when tm_isdst is forced to false 0. Wget's mktime_from_utc() forces tm_isdst=0 at a stage, and produces wrong by some minutes result only for one hour, beginning at DST transition plus one hour. (2) Replacing wget's mktime_from_utc() by a TZ=GMT0 mktime() scheme. Solves problem one, is faster, may seem cleaner (no discontinuities to support), but introduces portability issues. Still at discussion. (3) When wget's cmpt.c:mktime() is forced to override platform's mktime(), then mktime_from_utc() produces wrong results for two hours, beginning at to-DST transition plus two hours. Wrong by an hour less, or totally wrong. Even on platforms not affected by problem one. > I have been assuming that the behavior being observed was from a > mechanism similar to the "nonexistent localtime hour" issue currently > addressed in the code, so if you have explored that possibility and > ruled it out, I would benefit from your analysis. The nonexistant localtime hour is here the hour between 2:00 CET and 3:00 CEST. Problem one begins later at 4:00 CEST (until 5:00), while problem three begins at 5:00 CEST (until 7:00). Alain.
