The following code:

import locale, time
locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8")
t = time.localtime()
s = time.strftime('%c', t)
time.strptime('%c', s)

Raises

ValueError: time data '%c' does not match format 'Mer  9 jui 16:14:46 2010'

in any locale where month follows day in '%c' format.  Note that attached C code works as expected on my OSX laptop.

I wonder it it would make sense to call platform strptime where available? I wonder if platform support for strptime has improved since 2002 when _strptime.py was introduced.

Adding #8915 as a dependency because deducing D_T_FMT locale setting from strftime output seems impossible:

>>> locale.nl_langinfo(locale.D_T_FMT)
'%a %b %e %H:%M:%S %Y'

Victor,

You may be interested because your native language is implicated. :-)

time.strptime(s, '%c' ) ?

> time.strptime(s, '%c' ) ?

Oh my.  It certainly took a long time to recognize a silly mistake!

Thanks.

My tests were wrong but the problem does exist.  I am attaching a script that tests strptime(.., '%c') for all locales installed on my system (an unmodified  US Mac OS X 10.6.6).  

The only failing locale that I recognize is Hebrew (he_IL).  Eli, what do you think about this?

 
$ ./python.exe cfmt.py 
am_ET [ማክሰ ጃንዩ 11 18:56:18 2011] %A %B %d %H:%M:%S %Y != %a %b %e %H:%M:%S %Y
et_EE [T, 11. jaan  2011. 18:56:18] %a, %d. %B %Y. %H:%M:%S != %a, %d. %b %Y. %T
he_IL [EST 18:56:18 2011 ינו 11 ג'] %Z %H:%M:%S %Y %B %d %a != %Z %H:%M:%S %Y %b %d %a

- %T is equal for %H:%M:%S
- locales with %A and %B are broken on this platform as %c is "Appropriate date and time representation (%c) with abbreviations"

On Tue, Jan 11, 2011 at 7:26 PM, Roumen Petrov <report@bugs.python.org> wrote:
..
> - locales with %A and %B are broken on this platform as %c is "Appropriate date and time representation (%c) with abbreviations"

According to what standard? POSIX defines it as

%c Replaced by the locale's appropriate date and time representation.

http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html

and the manual page on my system agrees:

 %c    is replaced by national representation of time and date.

On Linux, cfmt.py fails on fr_FR locale (the only valid locale in the list of tested locales):
---
fr_FR [mer. 12 janv. 2011 11:30:35 CET] %a %d %B %Y %H:%M:%S %Z != %a %d %b %Y %T %Z
---

The problem is the month format: locale.nl_langinfo(locale.D_T_FMT) returns '%a %d %b %Y %T %Z', but _strptime (LocaleTime().LC_date_time) uses '%a %d %B %Y %H:%M:%S %Z' => '%b' vs '%B'.

_strptime.LocalTime.__calc_date_time() uses strftime('%c') and then parse the output to get the complete format. But it uses strftime('%c') with the march month, and in french, march is formatted 'mars' for both month formats (%b *and* %B).

_strptime.LocalTime.__calc_date_time() should detect that the month has the same format with %b and %B, and try other timestamps (other months).

Alexander, I get the same error for the he_IL locale. Will look into this

The problem for Hebrew appears to be the same as the one Victor stated for French. March in Hebrew is also a 3-letter word which means it's equal to its abbreviation.

I'm attaching a patch for Lib/_strptime.py that handles the month differently in __calc_date_time. It cycles all months, trying to find one where the full and abbrev names are different and matches it against the timestamp created by strftime. 

This solution is a hack, but so is the whole __calc_date_time function :-) [IMHO]

All tests pass and I also tried it manually with all the problematic locales reported by Alexander - seems to work correctly.

If this looks OK to you guys I can commit and backport.

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.

6. datetime.find(self.f_month[m]) >= 0 -> self.f_month[m] in datetime

Python is not C!

Alexander,

1) Patch comments - thanks for those. Will have them fixed.
2) General strategy for implementing strptime. I must confess I don't fully understand the reason for doing what the _strptime module does. Standard C AFAIK has nothing of the sort - it only has strftime and strptime, both using a given format string. Neither tries to guess it from an actual formatted time! Does it exist just to circumvent platforms where strptime isn't implemented in C or is buggy? Can you please shed some light on this (or point me somewhere)?

With understanding of (2) I will be able to also logically reason about the next steps :-)

You pretty much hit the nail on the head. Some platforms don't  have strptime or did not have it at the time this code was written. The locale module is probably more recent than this code as well.

Alexander, but still - this isn't just an implementation of strptime. strptime, AFAIU strptime gets the format string as a parameter and uses it to parse a date string into a "tm" struct. So why do we need to parse a date string *without* a format string in Python, resorting to heuristics and pseudo-AI instead?

Eli,

Given your last comment, are you still proposing your patch for inclusion or should we take the #8915 approach?