[issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change

[Joe Peterson]

New submission from Joe Peterson <joe at skyrush.com>:

DST is not handled correctly.  Specifically, when the input date/time, ignoring the TZ offset (and treated as if it is local time) is on the other side of the DST changeover from the actual local time represented, the result will be off by one hour.  This can happen, e.g., when the input date/time is actually UTC (offset +0000).

This is because the check for DST is done after converting the time into a local time tuple, thereby treating as real local time.  This can be corrected by keeping the time in real UTC (by using calendar.timegm() instead of checking the DST flag) until the final conversion to local time.

Here is an example:  Run the following two dates, that represent exactly the same time, through Internaldate2tuple:

'25 (INTERNALDATE "01-Apr-2000 19:02:23 -0700")'
'101 (INTERNALDATE "02-Apr-2000 02:02:23 +0000")'

Note that a variant of this issue (but identifying it as a different problem) was addressed in a similar way in an old post I found by Colin Brown in 2004 (http://www.velocityreviews.com/forums/t336162-imaplib-function-bug.html).

Patch also adds unit test to check the above example dates.  Python 3 version of patch assumes patch from issue 10939 has been applied.

Patch also corrects code python doc that currently states time is UT, not local (see issue 10934).

----------
components: Library (Lib)
messages: 126503
nosy: lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple produces wrong result if date is near a DST change
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________