On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32

Logged In: YES 
user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do 
some sanity checks on the values before returning and letting 
time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't 
overstep my bounds on the sanity checks (or I could just follow our own 
specs, but that would be too easy  =).

Logged In: YES 
user_id=357491

OK, have a solution coded up, just waiting to hear from Tim on whether a 
change to datetime is okay with him.

Logged In: YES 
user_id=263764

Not sure if it's helpful, but here's another data point. I
get the buggy behaviour on 2.3.3 on Gentoo Linux:

ratchet% python
Python 2.3.3 (#1, Jan  6 2004, 09:44:50)
[GCC 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)] on
linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
Segmentation fault

Logged In: YES 
user_id=357491

OK, fixed in Python 2.4 with rev. #2.140 for Modules/timemodule.c 
(along with changes to Doc/lib/libtime.tex as rev. 1.63, 
datetimemodule.c as rev. 1.70, Lib/test/test_time.py as rev. 1.16, and 
Lib/test/test_strftime.py as rev. 1.28).

This will break some code that does not use 1 or higher for fields in the 
time tuple that are supposed to be set to that (month, day, and day of 
year), but it was felt it was better to do a complete check on all values 
then on only certain values so as to make it consistent.

Since it breaks code it will not be backported.

And yes, ashtong, more data points are always helpful.