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

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 .

=) 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 tmisdst. 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