Joe Peterson j...@skyrush.com added the comment:
Great to hear, Alexander. Thanks for reviewing! Is it also possible to get
the pyhton2.7 version one in?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
Joe Peterson j...@skyrush.com added the comment:
The one you tried is the old patch. Here are the two new patches. Use these:
Python 2: issue10941_python2.diff
Python 3: issue10941_python3.diff
--
___
Python tracker rep...@bugs.python.org
http
Joe Peterson j...@skyrush.com added the comment:
OK, fixed patch to apply cleanly to current code. BTW, this is only for
python3. Is it still appropriate to patch python2? And if so, what is the
correct code repo to check out for that?
--
versions: +Python 3.4
Added file: http
Joe Peterson j...@skyrush.com added the comment:
I have now included a patch for 2.7. Here are the two latest patches:
Python 2: issue10941_python2.diff
Python 3: issue10941_python3.diff
--
Added file: http://bugs.python.org/file25297/issue10941_python2.diff
Joe Peterson j...@skyrush.com added the comment:
It's been over a year since any activity on this bug, and it is still in the
patch review stage. Any news? Anything else I can provide to help to get
this moved to the next stage? Thanks
Joe Peterson j...@skyrush.com added the comment:
Ah. I figured that one of the Python devs would be who would review it. Is
this the normal path for bugs? Not to question the process, but I find it
surprising, since I would think that it would cause a lot of bugs to stall out.
Also, I had
Joe Peterson j...@skyrush.com added the comment:
Thanks!! :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
___
___
Python-bugs-list
Joe Peterson j...@skyrush.com added the comment:
David, I understand - thanks for the details. Hopefully I can return the favor
and review one in the future.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
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
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
Joe Peterson j...@skyrush.com added the comment:
Here is a new patch that adds a test to the tests committed for issue 10939.
This new test case is needed to trigger the DST issue. This test is not
timezone-dependent (in the sense that one does not have to have a specific
timezone set
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
Changes by Joe Peterson j...@skyrush.com:
Removed file: http://bugs.python.org/file20613/issue10941.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
Joe Peterson j...@skyrush.com added the comment:
I like the idea of adding the decorator. New patch added.
--
Added file: http://bugs.python.org/file20615/issue10941.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
Joe Peterson j...@skyrush.com added the comment:
[just carrying over some info from issue 10939 that is related to this issue]
Here is another manifestation of this issue, related to the local time
assumption, but not to DST, per se:
Here is the definition for Europe/London in the unix tz
Changes by Joe Peterson j...@skyrush.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10947
___
___
Python-bugs-list
Joe Peterson j...@skyrush.com added the comment:
Also, isn't day supposed to be space- rather than 0- padded?
This is not clear to me. RFC2822 (referenced from RFC3501 for internal date)
discusses date formats, but as used in the header. In this case, day is
specified as ([FWS] 1*2DIGIT
Joe Peterson j...@skyrush.com added the comment:
Our messages crossed... :)
Hm, I see that in RFC 3501, as well (which obsoletes 2060).
But... I wonder: does (SP DIGIT) / 2DIGIT mean that 1 and 01 are both
OK? It seems ambiguous to me.
I still don't see why major IMAP servers
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
Joe Peterson j...@skyrush.com added the comment:
Here's a new patch. I would still like to discuss the leading space vs.
leading zero issue, but I have reverted to using a leading space in this patch
- fewer changes that way.
The long line is also fixed (sorry about that - yes, long lines
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:
Removed file:
http://bugs.python.org/file20587/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
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 Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
Joe Peterson j...@skyrush.com added the comment:
Not cryptic at all - looks great! New patch attached with associated tweaks.
--
Added file:
http://bugs.python.org/file20591/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep
Joe Peterson j...@skyrush.com added the comment:
Sebastian,
Yes, in fact Alexander Belopolsky (belopolsky) brought up the the locale issue
for this very function in one of the other issue comments.
The invert function, Internaldate2tuple(), actually does its own parsing using
a regex match
Joe Peterson j...@skyrush.com added the comment:
Yes, that's serious, certainly.
A patch should be fairly straightforward, given that part of the formatting
logic is already there (for the TZ offset at the end). You just need to format
the 6 values, and do a lookup for the month name
Joe Peterson j...@skyrush.com added the comment:
OK, I attached a patch that should work. Note that this patch works for Python
2 and Python 3.
As an aside, the str type is still returned as before (even in Python 3), and
the _month_names list uses str. As has been discussed, it may be more
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20556/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11024
Joe Peterson j...@skyrush.com added the comment:
Yep, I agree, and in light of this, we should probably just close this issue
and work toward reviewing/improving imaplib in the ways you are suggesting.
As I migrate my imap stuff more to Python3, I'll see if I run into any problems
with using
Joe Peterson j...@skyrush.com added the comment:
These are all good comments. And I agree that the naming of the functions is
not good (and the CamelCase).
Overall, yes, it should be made consistent and the types returned and passed in
should be appropriate. I did a little experimenting
New submission from Joe Peterson j...@skyrush.com:
In imaplib, there is currently a mix of bytes array and str use.
Time2Internaldate(), e.g., returns (and accepts) str. Internaldate2tuple() and
ParseFlags() only accept a bytes object, and the latter returns a tuple of
bytes objects
Joe Peterson j...@skyrush.com added the comment:
This issue has been split, as suggested by Alexander Belopolsky, into separate
issues:
issue 10934 - doc change to correctly reflect return of local time vs. UTC
issue 10939 - bytes/str issues
issue 10941 - DST handled incorrectly
issue 10947
Joe Peterson j...@skyrush.com added the comment:
Hey Alexander,
Looks great. Just a few small things:
* In hunk 2 of the imaplib.rst file patch section, insert word to (i.e.
Convert *date_time* to an IMAP4 ``INTERNALDATE`` representation.)
* Two lines, down there's only one space at end
New submission from Joe Peterson j...@skyrush.com:
Patched documentation for Internaldate2tuple() to correctly state it returns
local time.
Also, Time2Internaldate() (its inverse) did not state that it needs local time
as input, so patched this as well.
Patches for 3.2 and 2.7 are attached
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20439/imaplib_Internaldate2tuple_doc_python27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10934
Joe Peterson j...@skyrush.com added the comment:
I have started splitting these up as recommended. First one (documentation)
is: issue 10934. I will split out more later today...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Joe Peterson j...@skyrush.com:
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
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
bytes
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
Changes by Joe Peterson j...@skyrush.com:
--
keywords: +patch
Added file:
http://bugs.python.org/file20446/imaplib_Internaldate2tuple_dst_fix_python32.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20447/imaplib_Internaldate2tuple_dst_fix_python27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10941
Joe Peterson j...@skyrush.com added the comment:
Two more issues split out into their own issues:
issue 10939 (bytes/str issues)
issue 10941 (DST handled incorrectly)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Joe Peterson j...@skyrush.com added the comment:
I assume this means it raises a KeyError when given a bytes object as an
argument.
Yes, a KeyError is raised when arg is bytes, but passing a string also fails
(raising TypeError). The latter might also be a separate bug, in that strings
Joe Peterson j...@skyrush.com added the comment:
Added fix for ParseFlags (another string/bytes issue) and now accept strings as
args to ParseFlags and Internaldate2tuple.
Also added unit tests for changes.
--
assignee: - docs@python
components: +Tests
title: imaplib
Changes by Joe Peterson j...@skyrush.com:
Removed file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20431/imaplib_Internaldate2tuple_python32.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Changes by Joe Peterson j...@skyrush.com:
Removed file:
http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Changes by Joe Peterson j...@skyrush.com:
Added file:
http://bugs.python.org/file20432/imaplib_Internaldate2tuple_python27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Joe Peterson j...@skyrush.com added the comment:
There are at least 3 issues here: a documentation issue, a py3k bug and at
least one feature request.
Which is a feature request? In these patches, I am attempting to fix the DST
problems and regain the previous behavior in Python 2. Are you
New submission from Joe Peterson j...@skyrush.com:
Internaldate2tuple() is broken in several ways. The last two issues have
existed in the code for some time.
New issues in Python 3:
1. It crashes with KeyError. This is because the Mon2num dictionary's keys
are strings, not bytes objects
Changes by Joe Peterson j...@skyrush.com:
--
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
___
___
Python-bugs-list mailing
Changes by Joe Peterson j...@skyrush.com:
--
title: imaplib: Internaldate2tuple crashes, does not handle negative TZ
offsets, does not handle DST correctly, and outputs localtime (not UTC) -
imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets,
does not handle
Joe Peterson j...@skyrush.com added the comment:
Regarding problem #4, it actually appears that returning local time is the
right thing to do, since it matches the behavior of Time2Internaldate().
Returning UTC, as the doc states, would potentially break IMAP append() that
can include
Changes by Joe Peterson j...@skyrush.com:
Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
Changes by Joe Peterson j...@skyrush.com:
--
components: -Documentation
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
___
___
Python-bugs
Changes by Joe Peterson j...@skyrush.com:
--
components: +Documentation
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10921
___
___
Python-bugs
60 matches
Mail list logo
