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

Logged In: YES 
user_id=21868

This bug is still present in the 2.5 library. Will it be fixed?

Confirmed in trunk and py3k.

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.

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 .

I couldn't apply the py3k version of the patch which contains changed unit tests.  Would someone please review this patch.

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

-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.

I suppose this is a bug fix because it changes the behavior of email.utils.parsedate_tz() to match the RFC standards.

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?

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.

Attached a patch with just the y2k changes and new unit test, for the py3k branch.

Attached a patch with just the y2k changes and new unit test, for the trunk branch.

Added my copyright information to the patch for trunk.

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.

Removed copyright additions from patch.

Removed copyright additions from patch.

Applied in r84310.  Leaving issue open pending backport.

Thanks, Jeffrey.

Ported to 2.7 in r84311 and to 3.1 in r84312.