[ python-Bugs-1194222 ] parsedate and Y2K

[SourceForge.net]

Bugs item #1194222, was opened at 2005-05-02 21:37
Message generated for change (Settings changed) made by mnot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Nottingham (mnot)
Assigned to: Nobody/Anonymous (nobody)
Summary: parsedate and Y2K

Initial Comment:
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

----------------------------------------------------------------------

Comment By: Mark Nottingham (mnot)
Date: 2006-06-23 12:17

Message:
Logged In: YES 
user_id=21868

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470