Georg Brandl ge...@python.org added the comment:
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.
--
priority: normal - release blocker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Attached patch fixes the test (hopefully we don't have to support systems with
non-POSIX epoch) and cleans up whitespace.
--
resolution: - accepted
stage: patch review - commit review
Added file:
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file20604/issue10939.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file20605/issue10939.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed in revision 88231.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Merged to 3.1 in r88233.
--
nosy: +benjamin.peterson
resolution: accepted - fixed
stage: commit review - committed/rejected
versions: +Python 3.1
___
Python tracker
Joe Peterson j...@skyrush.com added the comment:
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.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
It looks like my test is not robust enough:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/298
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Some systems don't like times too close to epoch. Fixed in revision 88239.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Joe Peterson j...@skyrush.com added the comment:
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
Joe Peterson j...@skyrush.com added the comment:
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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, Jan 29, 2011 at 5:48 PM, Joe Peterson rep...@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
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20588/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: belopolsky - georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10939
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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.
--
assignee: - belopolsky
nosy: +belopolsky,
Changes by Joe Peterson j...@skyrush.com:
--
title: imaplib: Internaldate2tuple fails to parse month and does not work with
negative TZ offset due to bytes/str issues - imaplib: Internaldate2tuple
raises KeyError parsing month and does not work with negative TZ offset due to
18 matches
Mail list logo