Changes by Robert Collins robe...@robertcollins.net:
--
versions: +Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
Roundup Robot added the comment:
New changeset fa8b76dfd138 by Robert Collins in branch '3.4':
Issue #22932: Fix timezones in email.utils.formatdate.
https://hg.python.org/cpython/rev/fa8b76dfd138
New changeset 94b43b36e464 by Robert Collins in branch '3.5':
Issue #22932: Fix timezones in
Robert Collins added the comment:
Applied to 3.4 and up. Thanks for the patch!
--
nosy: +rbcollins
resolution: - fixed
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
Dmitry Shachnev added the comment:
Now the patch works with tzdata = 2011k, which is quite old.
@David: yes, with the unpatched version only one of the tests should fail.
--
Added file: http://bugs.python.org/file37721/issue22932_combined_v2.diff
Alexander Belopolsky added the comment:
Maybe Dmitry can come up with the skipif logic that will test for up-to date
tzinfo and skip the test if it is not. Otherwise we can try to come up with a
test case which is sufficiently far in the past.
--
R. David Murray added the comment:
Upgrading the timezone data results in passed tests. Without the fix, only one
of the tests fails. Is this intentional?
This, however, brings up the issue that the tests may fail on the buildbots,
which may also not have up to date timezone data :(
Dmitry Shachnev added the comment:
Can it be that you have outdated tzdata?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
R. David Murray added the comment:
Yes, that's possible. I will check.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
Changes by Dmitry Shachnev mity...@gmail.com:
Added file: http://bugs.python.org/file37683/issue22932_combined.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
R. David Murray added the comment:
The tests fail for me the same way both before and after the code patch:
==
FAIL: test_formatdate (test.test_email.test_utils.FormatDateTests)
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
Dmitry Shachnev added the comment:
This patch adds a test case for formatdate() function.
Before applying issue22932_v3.patch it fails, after applying that patch it
succeeds.
Sorry for the delay caused by holidays.
--
Added file: http://bugs.python.org/file37675/issue22932_test.patch
Akira Li added the comment:
@mitya57: Please, combine the code changes, tests, docs into a single
rietveld-compatible patch (hg diff); read devguide and
http://bugs.python.org/issue13963
Make sure review link appears on the right near the patch. Example:
http://bugs.python.org/issue22798
R. David Murray added the comment:
Is there any way to write a test for this?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
Changes by Akira Li 4kir4...@gmail.com:
--
nosy: +akira
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
___
Python-bugs-list mailing list
R. David Murray added the comment:
That's a bug (you will note that it causes a test failure in the email test
suite). - means this date is in UTC, but that may or may not be the local
timezone of the message. + means this date really is in the UTC
timezone. utils.format_datetime
Dmitry Shachnev added the comment:
Thanks, I did not know that. Here is version 3.
--
Added file: http://bugs.python.org/file37402/issue22932_v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
R. David Murray added the comment:
Yeah, only someone who has studied the RFCs would know that detail. I have no
idea whether or not any email clients/processors actually *use* that
distinction for anything, and I doubt there are very many humans who do :).
--
Alexander Belopolsky added the comment:
v3 looks good to me. BTW, I knew that the sign of TZ was significant, but
would have to look up the RFC to recall what the significance was. Thanks,
David, for the explanation.
--
___
Python tracker
Dmitry Shachnev added the comment:
Here is the updated patch based on Alexander’s suggestion.
Works fine, the only difference with previous behavior is that the zero time
zone is now + instead of -.
--
Added file: http://bugs.python.org/file37394/issue22932_v2.patch
New submission from Dmitry Shachnev:
The value of time.timezone may be wrong sometimes (see
http://bugs.python.org/issue22752), so I think the email library should not use
it:
$ python3 -c from email.utils import formatdate;
print(formatdate(localtime=True))
Mon, 24 Nov 2014 19:16:32 +0400
$
Alexander Belopolsky added the comment:
See also issue 665194.
--
nosy: +barry, r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
Alexander Belopolsky added the comment:
I was able to reproduce the problem on a Mac as follows:
$ TZ=Europe/Moscow date +%c %z
Mon Nov 24 19:27:51 2014 +0300
$ TZ=Europe/Moscow python3 -c from email.utils import formatdate;
print(formatdate(localtime=True))
Mon, 24 Nov 2014 19:28:03 +0400
Alexander Belopolsky added the comment:
Using something from datetime module works as expected:
$ TZ=Europe/Moscow python3 -c from datetime import datetime, timezone;
print(datetime.now(timezone.utc).astimezone())
2014-11-24 19:30:27.141542+03:00
--
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
stage: - needs patch
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
Dmitry Shachnev added the comment:
This patch fixes the issue for me.
--
keywords: +patch
Added file: http://bugs.python.org/file37266/issue22932.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
R. David Murray added the comment:
email.utils.format_datetime uses datetime. formatdate wasn't touched, for
backward compatibility reasons. If it has an actual bug we can fix it.
If it can be converted to use datetime without sacrificing backward
compatibility, that's also fine with me.
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: needs patch - patch review
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22932
___
Alexander Belopolsky added the comment:
The proposed patch will not work on platforms that don't support tm_gmtoff. A
proper fix may look like this:
dt = datetime.fromtimestamp(timeval, timezone.utc)
if localtime:
dt = dt.astimezone()
return format_datetime(dt, usegmt)
--
30 matches
Mail list logo
