[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