New submission from Joe Peterson <j...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue10941> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
