[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4