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

Brett Cannon bac@OCF.Berkeley.EDU
Mon, 13 Jan 2003 18:42:25 -0800 (PST)


[Tim Peters]

> [Brett Cannon]
> > ...
> > 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?
>
> I doubt it, but toordinal() and weekday() won't go away or change.  Even if
> timetuple() changes, the "Julian day" would still be easily gotten via:
>
>     (d - d.replace(month=1, day=1)).days + 1
>
> The potential problem with timetuple() now is that /F's spec says it returns
> (machine) local time, and if we adopt that then the day may change from
> what's returned now (time zone adjustment can move you one day in either
> direction).
>

I will just hold off for now but plan on making the switch before 2.3 goes
final.

> > Or should I hold off for a little while?  Might as well cut back on the
> > code duplication as much as possible.
>
> Code dup was my main concern, and these algorithms are irritating enough
> that it would be good to fix bugs in only one place <wink>.
>

=)  You can say that again.

> > 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).
>
> There's no desire on my or Guido's parts, although I'm not entirely sure why
> not.  A large part of it for me is just avoiding another time sink.
>

Well, I would assume the responsibility of maintaining it would fall on
my shoulders.  But leaving it out is fine with me.

> As to the rest, I bet we'll be fine if you just plug in the most reasonable
> values you can, and that aren't likely to tickle platform bugs.  That means
> 1900 for an unspecified year, no months outside 1-12, no days below 1, etc.
> No leap seconds either, and no -1 except for tm_isdst.  That should give
> Kevin the roundtrip date behavior he needs, and shouldn't screw anyone.
>

OK, I will then plan on writing up a patch to give reasonable default
values to ``_strptime``.  I will wait a week, though, to make sure there
are no latent comments on any of this.

Also, is there any desire for the C wrapper to do any checking of the
values so we can change the docs and guarantee that any value returned by
``time.strptime()`` will have valid values?

-Brett