On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky <report@bugs.python.org> wrote:
..
> This solution is a hack, but so is the whole __calc_date_time function :-) [IMHO]
>

I am not sure how to proceed.   On one hand, I opened this issue to
demonstrate that the current implementation is flawed, on the other
hand, Eli has succeeded in improving the hack so that we can live with
it a bit longer.  Note that I did not have any real life application
that would misbehave because of this bug and I don't think developers
expect %c format to be parseable in the first place.

I made this issue depend on #8915 because I think strptime should
query the locale for format information directly rather than reverse
engineer what strftime does.

I don't think this fix solves all the problems.  For example, in most
locales (including plain C locale), day of the month in %c format uses
%e format, but current implementation guesses it as %d:

'%a %b %e %H:%M:%S %Y'
>>> LocaleTime().LC_date_time
'%a %b %d %H:%M:%S %Y'

This does not seem to be an issue because strptime with %d seems to be
able to parse space-filled as well as zero-filled numbers.  However,
there may be platforms that are less forgiving.

On the patch itself:

1. Unit tests are needed.

2. Please don't use datetime as a local variable.

3. I am not sure what the purpose of .lower() is.  Are a_month and
f_month lowercased?

4. Please keep lines under 79 characters long.

5. "for m in range(1, 13)" loop is better written as "for am, fm in
zip(self.a_month, self.f_month)"

Eli, what do you think yourself:  should we try to perfect the hack or
is it better to reimplement strptime using locale?  Note that the
latter may be a stepping stone to implementing strftime as well.