This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lavajoe
Recipients lavajoe
Date 2011-01-18.23:41:44
SpamBayes Score 3.4970027e-10
Marked as misclassified No
Message-id <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2011-01-18 23:41:47lavajoesetrecipients: + lavajoe
2011-01-18 23:41:47lavajoesetmessageid: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
2011-01-18 23:41:44lavajoelinkissue10941 messages
2011-01-18 23:41:44lavajoecreate