[Python-Dev] Broken strptime in Python 2.3a1 & CVS

Brett Cannon bac@OCF.Berkeley.EDU
Mon, 13 Jan 2003 12:56:41 -0800 (PST)


[Kevin Jacobs]

> On Mon, 13 Jan 2003, Tim Peters wrote:
> > [Kevin Jacobs]
>
> I'm not sure what else you expect of me.  I have an application, some
> anecdotal evidence that something is amiss, reported specific test-code that
> that demonstrated problem, and encouraged Brett do a bit of digging though
> the standards to see if he can improve things.
>

I think what Tim is looking for is an explicit spelling of what standards
you initially mentioned were.  It appears you were not thinking of any
specifically (in terms of ``strptime()``, but you did mention
``time.mktime()``'s).

I see a few solutions to all of this:

	1) Change nothing -- Keeps my life simple, but Kevin doesn't get
his use case fixed.

	2) Define our own standard on return values -- This would require
editing timemodule.c to make sure any C version that gets used conforms to
what we specify.  The other option is to just remove the C version and use
the Python version exclusively; speed and backwards-compatibility be
damned, although the docs leave such a big hole open for what ``strptime``
will do that it would still conform to the docs.  =)

	3) Change ``time.mktime()`` code -- We can make the function
ignore all -1 values if we cared to since our docs say nothing about
supporting negative values.

	4) Change ``time.mktime()`` docs -- Warn that it can, on occasion,
accept negative values as valid (need to check ISO C docs to see if it always accepts negative values or
if this is a "perk" of some other spec)

	5) Create ``time.normalize()`` -- Would take a struct_time and
return a new one with values that are within the valid ranges.  This
doesn't lead to us coming up with standards for ``strptime`` and allows
people like Kevin to make sure any struct_time objects they use won't have
unsuspected values.


We should at least do 4) (and I will write the doc patch if people agree
this should be done).  I have no issue doing 2) since I would think we
would just force all unreasonable values to the smallest valid value
possible (sans things that can be calculated such as day of the week and
Julian day to make sure they are valid).  I have no clue how often
negative values are used in ``time.mktime()``, so I can't comment on 3).
5) is just an idea off the top of my head.

And I obviously have not great objection to 1).  =)

-Brett