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

[Tim Peters]

[Brett Cannon]
> 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).

Right, it's a bug nest no matter how you look at it, and "the standards"
appear of no use in sorting it out.

> But otherwise I am fine with it defaulting to 1900-01-00 as Kevin seems
> to be suggesting.

It's hard to know what Kevin was suggesting -- he was mostly appealing to
emperors that turn out to have no clothes <wink>.

> But a perk of my strptime implementation is that I researched equations
> that can calculate the Julian day based on the Gregorian date values,
> Gregorian values based on the year and Julian day, and day of the week
> from the year, month, and day.  This means that if I set day to 1 if it
> was not given by the user, then the Gregorian calculation will figure out
> that it should be 1900-01-01; I would like to use that calculation.

You don't need to do any of that so long as you're using Python 2.3:  the
new datetime module can do it for you, and at C speed:

>>> import datetime
>>> datetime.date(1900, 1, 1).weekday()
0
>>> datetime.date(1900, 1, 1).timetuple()
(1900, 1, 1, 0, 0, 0, 0, 1, -1)
>>>

etc.

> Now I could special-case all of this so that this quirky business of the
> day of the month being set to 0 is implemented.  But I would much rather
> return valid values if I am going to have to have default values in the
> first place.  So does anyone have any objections if I default to the date
> 1900-01-01 00:00:00 with a timezone of 0

The last bit there is the tm_isdst flag, which only records DST info.
datetime returns -1 there which is explicitly defined as "don't know" --
without a real time zone attached to a date, datetime can't guess whether
DST is in effect, and uses -1 to communicate that back to the caller.

> and then calculate the Julian day and day of the week?  That way the
> default values will be valid *and* not mess up ``time.mktime()``?

Kevin is the only one with a real use case here so far, and he needs to
define what he wants with more rigor.  It may or may not turn out to be
feasible to implement that, whatever it is.