[Python-Dev] Broken strptime in Python 2.3a1 & CVS (original) (raw)

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