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

[Brett Cannon]

[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 tm_wday and tm_yday 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