Joe Peterson added the comment:
Great to hear, Alexander. Thanks for reviewing! Is it also possible to get
the pyhton2.7 version one in?
--
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson 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
<http://bugs.python.org/issue10
Joe Peterson 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 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://bugs.python.org
Joe Peterson added the comment:
David, I understand - thanks for the details. Hopefully I can return the favor
and review one in the future.
--
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson added the comment:
Thanks!! :)
--
___
Python tracker
<http://bugs.python.org/issue10941>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Peterson 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 no idea it was
Joe Peterson 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 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 data:
# Zone NAME
Joe Peterson 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
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20613/issue10941.diff
___
Python tracker
<http://bugs.python.org/issue10941>
___
___
Python-bugs-list m
Joe Peterson 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
Joe Peterson 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 for it to work), but
Joe Peterson 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 interpret the values
Joe Peterson 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
Joe Peterson 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
<http://bugs.python.
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20588/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20587/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson 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 are ugly). A
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Joe Peterson 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
Joe Peterson 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)&qu
Changes by Joe Peterson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10947>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20556/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Joe Peterson 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 proper
to
Joe Peterson 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.
If you want to t
Joe Peterson 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 (and so does not
Joe Peterson 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 bytes throu
Joe Peterson 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, using more imaplib
Joe Peterson 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
Joe Peterson 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 - compatibility
New submission from Joe Peterson :
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. Of course, these were
Joe Peterson added the comment:
Two more issues split out into their own issues:
issue 10939 (bytes/str issues)
issue 10941 (DST handled incorrectly)
--
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20447/imaplib_Internaldate2tuple_dst_fix_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
--
keywords: +patch
Added file:
http://bugs.python.org/file20446/imaplib_Internaldate2tuple_dst_fix_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
New submission from Joe Peterson :
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
Changes by Joe Peterson :
--
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/str iss
New submission from Joe Peterson :
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. The sign
Joe Peterson 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
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20439/imaplib_Internaldate2tuple_doc_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
New submission from Joe Peterson :
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
Joe Peterson 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 talking
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20432/imaplib_Internaldate2tuple_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20431/imaplib_Internaldate2tuple_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Joe Peterson 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: Internaldate2tuple() cras
Joe Peterson 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
cannot be
Changes by Joe Peterson :
--
components: +Documentation
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Joe Peterson :
--
components: -Documentation
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Joe Peterson 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 an internaldate
Changes by Joe Peterson :
--
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 DST correc
Changes by Joe Peterson :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Joe Peterson :
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 obj
60 matches
Mail list logo
