| msg25216 - (view) |
Author: Mark Nottingham (mnot) |
Date: 2005-05-03 04:37 |
| rfc822.parsedate and email.Utils.parsedate don't take Y2K into account when parsing two-digit years, even though they're allowed by RFC822. Even though that spec has since been superseded, there are still systems generating dates in the old format, and RFC2616, which bases its dates on RFC822, still allows two-digit years. For example, >>> email.Utils.parsedate("Sun, 6 Nov 94 08:49:37 GMT") (94, 11, 6, 8, 49, 37, 0, 0, 0) Here's a trivial patch to behave as outlined in the time module (I don't test for time.accept2dyear because the input is outside the system's control, and RFC-specified); it's against 2.3, but should be easy to integrate into later versions. 125a126,130 > if yy < 100: > if yy > 68: > yy = yy + 1900 > else: > yy = yy + 2000 |
|
|
| msg25217 - (view) |
Author: Mark Nottingham (mnot) |
Date: 2006-06-23 19:17 |
| Logged In: YES user_id=21868 This bug is still present in the 2.5 library. Will it be fixed? |
|
|
| msg83125 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-03-04 15:21 |
| Confirmed in trunk and py3k. |
|
|
| msg99647 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-02-21 06:00 |
| Here's a patch which changes the behavior of email.utils.parsedate_tz() so that it always returns a four-digit year. I've also included some other simple changes to make some of the surrounding code a little bit clearer. The code review can be found at http://codereview.appspot.com/216064. |
|
|
| msg99967 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-02-23 23:01 |
| Oh, that previous patch was for the 2.7 branch. Here's a patch for the py3k branch, and a codereview at http://codereview.appspot.com/217107 . |
|
|
| msg114496 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-08-21 14:27 |
| I couldn't apply the py3k version of the patch which contains changed unit tests. Would someone please review this patch. |
|
|
| msg114498 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-21 15:00 |
| Sorry about that; the diff paths have the "a/" and "b/" prefixes. Patch with -p1 at the top-level directory: patch -p1 < issue1194222fix-py3k.diff |
|
|
| msg114499 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-08-21 15:04 |
| -p1 is the default for patch, so it should work. Is this a bug fix or a feature request? It’s unclear. If it’s a bug fix, please add 2.7 and 3.1 to versions. |
|
|
| msg114501 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-21 15:31 |
| I suppose this is a bug fix because it changes the behavior of email.utils.parsedate_tz() to match the RFC standards. |
|
|
| msg114506 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-08-21 16:28 |
| What I wrote on Rietveld: I don’t know much about email, but the code itself looks good to me. The fact that you didn’t have to change any test but added one is reassuring (unless it reveals lack of coverage). http://codereview.appspot.com/217107/diff/1/2#newcode1 Lib/email/_parseaddr.py:1: # Copyright (C) 2002-2007, 2010 Python Software Foundation “2002-2010” would make more sense. http://codereview.appspot.com/217107/diff/1/2#newcode24 Lib/email/_parseaddr.py:24: DOY_UNKNOWN = 1 Can you add a comment explaining what DOY means, unless it’s obvious for email specialists? |
|
|
| msg114765 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-24 02:07 |
| Thanks for working on this. I would prefer to have two patches: one that fixes the bug (and adds the unit tests) and a separate one for the cleanups (in a new issue). I agree that the fact that it isn't complying with the RFC makes it a bug. It seems unlikely that fixing this would break anyone's code, since if they are already working around the bug the return of a four digit year should cause their workaround code to be skipped. |
|
|
| msg114801 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-24 18:19 |
| Attached a patch with just the y2k changes and new unit test, for the py3k branch. |
|
|
| msg114802 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-24 18:21 |
| Attached a patch with just the y2k changes and new unit test, for the trunk branch. |
|
|
| msg114803 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-24 18:50 |
| Added my copyright information to the patch for trunk. |
|
|
| msg114815 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-24 20:14 |
| Adding a copyright notice for a patch is not something that we generally do (and your current mod is implicitly claiming the whole file, which doesn't seem right in any case). My understanding is that US copyright law says you have the copyright whether there's a notice or not, so you don't have to worry about putting anything in there (even assuming such a small piece of code is copyrightable, which is debatable). Signing the contributor agreement is enough to grant redistribution rights to the code, regardless, so really nothing needs to be added. |
|
|
| msg114833 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-24 21:26 |
| Removed copyright additions from patch. |
|
|
| msg114834 - (view) |
Author: Jeffrey Finkelstein (jfinkels) * |
Date: 2010-08-24 21:27 |
| Removed copyright additions from patch. |
|
|
| msg114860 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-25 00:48 |
| Applied in r84310. Leaving issue open pending backport. Thanks, Jeffrey. |
|
|
| msg114876 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-25 02:01 |
| Ported to 2.7 in r84311 and to 3.1 in r84312. |
|
|