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 talking about 
the ability to accept a string vs. a bytes object?

> 1. Internaldate2tuple is documented to return UTC timetuple, but implemented 
> to return local time (ignoring the DST issues.)  The proposal is to change 
> the documentation.

I prefer UTC, so this is a bit of a shame, I agree, but the use of the pervious 
interfaces assumed localtime, so changing to UTC would definitely break 
existing code.  I do think it would be nice to extend this to deal with UTC 
instead, but in this patch, I am only trying to retain current functionality.

2. There are a couple of str vs bytes bugs that obviously need to be fixed.

> 3. The proposed patch also make both str and bytes acceptable as 
> Internaldate2tuple argument.

True, but given the new role of str and bytes, it is unclear what existing code 
would try to pass.

> As discussed in issue 9864, it would be best if datetime formatting and 
> parsing routines would operate on datetime objects.

I can see that redoing some of this would be a good idea.  But I am only trying 
to keep the existing stuff from being broken in this patch.  I agree that the 
interfaces could be a lot better, and I would indeed like to see it improved 
(and I am willing to help with doing that).

> There is still a problem, though.  The code above would only work as expected 
> in the C locale, but Time2Internaldate already has this limitation.

As long as we assume strings passed are ASCII, it should work.  And email 
headers should be ASCII (although I have seen some really weird deviations from 
this on old emails).  It's not perfect, certainly, and going forward, the IMAP 
lib could be tightened up.  Maybe this first patch could be thought of as a 
step, at least fixing what is broken until improved.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to