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

Tim Peters tim.one@comcast.net
Mon, 13 Jan 2003 21:20:08 -0500

[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).

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 .

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.

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.