On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
<report@bugs.python.org> wrote:
..
> Hmm. My search brought up issue 10563, but the last message on that
> issue says that "a change has been recently made to time.asctime() to
> reject year > 9999.  See r85137 and issue6608."  I wonder if that
> change made this issue moot.

It turns out the check added in r85137 does not cover tm_year even
though CERT recommends it (see msg107605).  These are separate issues
though. I think given where we are in the release cycle, the most
conservative solution would be to simply add a null check as follows.
(I did check that it fixes the crash on OSX.)

===================================================================
--- timemodule.c        (revision 87556)
+++ timemodule.c        (working copy)
@@ -620,6 +620,10 @@
     } else if (!gettmarg(tup, &buf) || !checktm(&buf))
         return NULL;
     p = asctime(&buf);
+    if (p == NULL) {
+        PyErr_SetString(PyExc_ValueError, "invalid time");
+        return NULL;
+    }
     if (p[24] == '\n')
         p[24] = '\0';
     return PyUnicode_FromString(p);