There are two issues with conversion to Python 3:

1. It raise "KeyError".  This is because the Mon2num dictionary keys are strings (str), not bytes objects (note that many other strings in imaplib have been updated, but not Mon2num).

2. The sign character of the TZ offset (e.g. -0700) is compared to the string (str) '-', not bytes array b'-', so the compare is never true, causing a large error when the TZ offset is negative.

Patch attached that also adds a unit test.

Georg,

This is an obvious artifact of an untested py3k port.  Can this go in 3.2?

The patch looks good except for a long line in the test which I can take care of.

The new test is faulty; it appears to be specific to the timezone of the patch submitter.

The library fix should go in nevertheless, if you could add a correct test, Alexander, it would be great.

Attached patch fixes the test (hopefully we don't have to support systems with non-POSIX epoch) and cleans up whitespace.

Committed in revision 88231.

Merged to 3.1 in r88233.

Good catch on the test.  Note that for issue 10941, we'll want a new non-timezone-dependent test case that can catch the DST-related problem.  I'll post a new patch to issue 10941 now and describe this some more there.

It looks like my test is not robust enough:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/298

Some systems don't like times too close to epoch.  Fixed in revision 88239.

Alexander, looks like you hit a weirdness in the Europe/London timezone for dates before 31-Oct-1971, as if DST was in effect even in winter.  And the fail of the test is caused by the same bug that causes issue 10941: the use of mktime to interpret the values from an internal time string (which should not be dealing with timezones, but rather explicit offsets from UTC, before converting to localtime).

More info on the Europe/London "near the epoch" thing (there is no weirdness in the tz stuff - it's just issue 10941 causing the test to fail)...

I looked at the sources for the tz data, and here is the definition for Europe/London:

# Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
Zone	Europe/London	-0:01:15 -	LMT	1847 Dec  1 0:00s
			 0:00	GB-Eire	%s	1968 Oct 27
			 1:00	-	BST	1971 Oct 31 2:00u
			 0:00	GB-Eire	%s	1996
			 0:00	EU	GMT/BST

I appears that London was always 1 hour ahead (BST time) from 1968 Oct 27 until 1971 Oct 31 2:00u, thus triggering issue 10941:

Internaldate2tuple() actually returns the wrong local time (00:00 rather than [the correct] 01:00) in its tuple for the epoch, so mktime(), doing the right thing, returns -3600.  The patch in issue 10941 fixes this, so the right local time in London (01:00) is returned for the epoch (internal date string "01-Jan-1970 00:00:00 +0000").

Note that this also exposes another problem with Time2Internaldate(), since it uses time.timezone/time.altzone, which are only valid for the current rules, not old rules as in the London case near the epoch.

On Sat, Jan 29, 2011 at 5:48 PM, Joe Peterson <report@bugs.python.org> wrote:
..
> Note that this also exposes another problem with Time2Internaldate(), since it uses
> time.timezone/time.altzone, which are only valid for the current rules, not old rules as in the London case
> near the epoch.

This is a known issue.  Hopefully this example will raise more
interest for issue 9527.  See also issue 1647654 which suggests a
python-only work-around.