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

Brett Cannon bac@OCF.Berkeley.EDU
Wed, 8 Jan 2003 16:14:46 -0800 (PST)

[Kevin Jacobs]

On Wed, 8 Jan 2003, Brett Cannon wrote: > [Kevin Jacobs]

I suspect that I know the cause, though I have not looked at the source for the specific code. Basically, your strptime implementation leaves unspecified information as -1. This is nice, except that it violates the SVID 3, POSIX, BSD 4.3, ISO 9899 standards.

Ah, nuts. You are right, _strptime does set unknown values to -1; Python docs say that unknown values might be set to who-knows-what, so I figured -1 was obvious since none of the values can be -1.

Seems some people don't like that idea. Bah!

i.e., here is an exerpt from

the mktime man page on my linux system on how the values in a time-tuple are interpreted:

The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the specified contents of the structure members tmwday and tmyday and recomputes them from the other information in the broken-down time structure. If structure members are outside their legal interval, they will be normalized (so that, e.g., 40 October is changed into 9 Novem- ber). Thus, mktime correctly returns a time-from-epoch that is 1 hour, 1 minute, and 1 second (3661 seconds) behind where it should be (unless it is DST).

How lovely. OK, so I am up for suggestions. I mean I could return default values that are within the acceptable range (one-line change since I just initialize the list I use to store values with default values of -1 as it is), but I don't want to mislead users into thinking that the values were extracted from the data string. Does obviousness come before or after following a spec? Would setting default values within range but to their minimum value (so if the month is not known, set it to 1 for Jan instead of -1) solve your problem, Kevin?

-Brett