I ran 

python test_time.py 

and python immediately crashed.

This is the trace from mac's error reporter: 

http://dpaste.de/Jsw7/

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Python crashes when dereferencing 0x0000000000000018, which is NULL + 24

This means that it crashes here:

     p = asctime(&buf);
     if (p[24] == '\n')
         p[24] = '\0';

No check is made on asctime(3) return's value, so if it returns NULL, we'll segfault.

I think the problem is that gettmarg doesn't check its returned struct tm.

Also, in time_strtime, there's this comment:

 Checks added to make sure strftime() does not crash Python by
 
414        indexing blindly into some array for a textual representation
 
415        by some bad index (fixes bug #897625).
 
416  

Is there any good reason why those checks aren't performed directly in 
gettmarg ?

From the path names in the trace you appear to have a MacPorts Python 2.7 installed.  For what it's worth, the standard library test_time works for me on OS X 10.6.6 with a current MacPorts 2.7.1 as well as a python.org 2.7.1.  Exactly how did you try to run this, i.e. what are the results of:
   $ which python
   $ echo $pwd
   $ ls -l test_time.py

True with the following:

import time

time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))

You'll get a segfault.

$ /opt/local/bin/python2.7
Python 2.7.1 (r271:86832, Dec 31 2010, 11:59:23) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))
'Mon Feb 26 -1:00:00 2011'
>>> ^D
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Python 2.7.1+ (release27-maint, Jan 29 2011, 13:55:30) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))
'Mon Feb 26 -1:00:00 2011'
>>> ^D

This explains why you don't get a segfault: your libc is broken ;-)

If it's broken, complain to Apple.

$ otool -L $(/opt/local/bin/python2.7 -c 'import time;print(time.__file__)')
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

That still doesn't explain the OP's crash on OS X 10.6.6.

> If it's broken, complain to Apple.

Actually, I checked glibc's asctime, and it has the same behaviour. But the point is that asctime can return NULL.

> That still doesn't explain the OP's crash on OS X 10.6.6.

Yes it does. If asctime returns NULL, you'll segfault.
Now, if you ask me why he's encoutering this bug, I'd guess that he's using py3k' test_time.py, which added tests feeding invalid tuples to time.asctime. But it's just a wild guess.

Anyway, the code in python 2.7 is buggy, and must be fixed.

I updated my local svn checkout, and the code has been fixed recently:


  r87648 | alexander.belopolsky | 2011-01-02 15:48:22 -0500 (Sun, 02 Jan 2011) | 1 line
  
  Issue #8013: Fixed time.asctime segfault when OS's asctime fails


    p = asctime(&buf);
    if (p == NULL) {
        PyErr_SetString(PyExc_ValueError, "invalid time");
        return NULL;
    }
    if (p[24] == '\n')
        p[24] = '\0';


So I'd suggest to close this issue.