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

[Brett Cannon]

[Tim Peters]

> [Brett Cannon]
> > OK, so I read the Open Group's specification and it had squat for default
> > value info
>
> Read it again:  the notion of "default value" makes no sense for the C
> strptime(), because a struct tm* is both input to and output from the C
> version of this function.  The caller is responsible for setting up the
> defaults they want in the struct tm passed *to* strptime().  The Python
> strptime doesn't work that way (no timetuple is passed on), which makes the
> "default values" issue more intense in the Python version.
>

And the reason I set values to -1 in the first place is because the Python
docs say that there is no guarantee as to what will be returned.  Why
chouldn't they had added this function to ISO C?

> > (unless what they provide online is not as detailed as what
> > members have access to).
>
> Nope, that's all there is.
>

Figures.

[stuff about how lacking the "standards" are for the C implementation]
> It's hard to know what Kevin was suggesting -- he was mostly appealing to
> emperors that turn out to have no clothes <wink>.
>

=)  It would seem that Kevin would be happy as long as he can pass a
struct_time straight from ``strptime()`` to ``time.mktime()`` and have the
result be what he expects.

> > But a perk of my strptime implementation is that I researched equations
> > that can calculate the Julian day based on the Gregorian date values,
> > Gregorian values based on the year and Julian day, and day of the week
> > from the year, month, and day.  This means that if I set day to 1 if it
> > was not given by the user, then the Gregorian calculation will figure out
> > that it should be 1900-01-01; I would like to use that calculation.
>
> You don't need to do any of that so long as you're using Python 2.3:  the
> new datetime module can do it for you, and at C speed:
>
> >>> import datetime
> >>> datetime.date(1900, 1, 1).weekday()
> 0
> >>> datetime.date(1900, 1, 1).timetuple()
> (1900, 1, 1, 0, 0, 0, 0, 1, -1)
> >>>
>
> etc.
>

Well, since this code was added in 2.3a0 and I have no API to worry about
I can easily make use of the code.  Is the datetime API all settled after
the last shakedown of the class hierarchy?  Or should I hold off for a
little while?  Might as well cut back on the code duplication as much as
possible

And I take it there is no desire to integrate strptime into datetime at
all (I remember someone saying that this would be going in the wrong
direction although you do have strftime).

> > Now I could special-case all of this so that this quirky business of the
> > day of the month being set to 0 is implemented.  But I would much rather
> > return valid values if I am going to have to have default values in the
> > first place.  So does anyone have any objections if I default to the date
> > 1900-01-01 00:00:00 with a timezone of 0
>
> The last bit there is the tm_isdst flag, which only records DST info.
> datetime returns -1 there which is explicitly defined as "don't know" --
> without a real time zone attached to a date, datetime can't guess whether
> DST is in effect, and uses -1 to communicate that back to the caller.
>

OK, I will leave it as -1 then as the default.

> > and then calculate the Julian day and day of the week?  That way the
> > default values will be valid *and* not mess up ``time.mktime()``?
>
> Kevin is the only one with a real use case here so far, and he needs to
> define what he wants with more rigor.  It may or may not turn out to be
> feasible to implement that, whatever it is.
>

OK, then I won't bother with a patch until Kevin explicitly says exactly
what he wants.  And if there is a specific requirement that he wants I
would suspect that there will need to be some new C code added to
timemodule.c since strptime has no guarantees in terms of standards and
just having _strptime conform won't be enough (especially while it is only
a backup for the C version).

Yay, less work for me.  =)  Thanks, Tim.

-Brett