[Python-Dev] Boundary checks on arguments to time.strftime()

[Tim Peters]

[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).