RE: Broken strptime in Python 2.3a1 & CVS
Tim Peters <tim.one <at> comcast.net>
2003-01-13 04:30:14 GMT
> OK, so I read the Open Group's specification and it had squat for default
> value info
Read it again: the notion of "default value" makes no sense for the C
strptime(), because a struct tm* is both input to and output from the C
version of this function. The caller is responsible for setting up the
defaults they want in the struct tm passed *to* strptime(). The Python
strptime doesn't work that way (no timetuple is passed on), which makes the
"default values" issue more intense in the Python version.
> (unless what they provide online is not as detailed as what
> members have access to).
Nope, that's all there is.
> So I logged into a Solaris machine with 2.1.1 and ran
> ``time.strptime('January', '%B')`` and got
> (1900, 1, 0, 0, 0, 0, 6, 1, 0)
> (which is strange because the day of the week for 1900-01-01
The timetuple you got back on Solaris is for the senseless "day" 1900-01-00:
tm_mday is 1-based, not 0-based.
> is Monday, not Sunday;
But if 1900-01-00 *were* a real day <wink>, it would be a Sunday.
> must be rolling back a day since the day is 0? But then the Julian day
> value is wrong).