Comment 2 for bug 711541

The problem seems to be caused by the fix to bug 564607 ( https://bugs.launchpad.net/python/+bug/564607 ) which is a fix to issue 762963 in python ( http://bugs.python.org/issue762963 ). The "fix" doesn't seem settled in the python community. In the python2.6 source package the patch file in debian/patches/issue762963.diff contains the "fix".

The source of the problem seems to be the addition of a call to mktime. What the code does with the "fix" is to
(1) zero struct tm *p
(2) call mktime(p) which sets timezone/dst information
(3) then fill in the rest of the tm structure with the date/time we are converting
This leads to the wrong dst information being used if our current dst is not in agreement with the dst of the time we are converting. This issue is really in gettmarg().

Attached is a program that shows the problem. In this program a struct tm buffer is created and zeroed. mktime is then called and the elements of struct tm printed. Next the date/time entries are filled in and strftime() is called. Finally the timezone information is zeroed in the structure and strftime() is called again. I find the following results:

Ubuntu 10.10 or 11.04 machine:
0 0 0 31 11 -1 0 364 0 -18000 EST <-- Oddly some entries are set
Sun Jul 4 12:23:45 2010 EST <-- Incorrect timezone
Sun Jul 4 12:23:45 2010 EDT <-- correct timezone

Debian Squeeze machine:
0 0 0 0 0 0 0 0 0 0 (null)
Sun Jul 4 12:23:45 2010 EDT
Sun Jul 4 12:23:45 2010 EDT

OpenBSD4.8 machine:
0 0 0 0 0 0 0 0 0 0 (null)
Sun Jul 4 12:23:45 2010 EDT
Sun Jul 4 12:23:45 2010 EDT

Notice that the Ubuntu machines reset some of the fields:
tm_mday = 31
tm_mon = 11
tm_year = -1
tm_yday = 364
plus the timezone related fields. The Debian machine doesn't.

Perhaps this really is an issue in eglibc and/or some changes in eglibc have obviated the need for this patch.

On Ubuntu 11.04 the patch issue762963.diff is included in the source package for python2.7 but is NOT applied, thus the python test code given in the original report runs correctly.