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

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

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

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