[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Alexander Belopolsky
report at bugs.python.org
Sat Jan 15 17:42:28 CET 2011
Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky <report at 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.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________
More information about the Python-bugs-list
mailing list