[Guido]
... Agreed. How could an out-of-range causes crashes in the implementation *and* be a required feature?
The intersection of "causes crashes" and "required features" consists of platform C library bugs. The potential behavior changes go beyond that intersection, though: timemodule.c uses gettmarg() to build struct tm thingies. mktime() specifically allows struct tm fields to be out of range, but time.mktime() uses gettmarg(), so if the latter starts complaining, *some* existing uses of time.mktime() will start complaining too. We hit this in a small way when calender.timegm() was changed to use the datetime module: days = datetime.date(year, month, day).toordinal() - _EPOCH_ORD started complaining about senseless y,m,d triples then, and a user did file a bug report against that. The code was changed to the goofy: days = datetime.date(year, month, 1).toordinal() - _EPOCH_ORD + day - 1 instead so they could continue using senseless (wrt the specified year and month) days. "Legacy API"s are always touchy. We have one report of a crash now, due to using a negative tm_wday value in a tuple passed to strftime(). strftime() may want to gripe about that, but mktime() may not (the C std specifically requires that the mktime() implementation ignore the input value of tm_wday, so if any platform crashes on a negative tm_wday input to mktime(), that would be a platform C bug).