[Python-Dev] strftime/strptime locale funnies...

[Donovan Baarda]

G'day,

Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old)
based systems Python's time.strptime() seems to ignore the environment's
Locale and just uses "C".

Last time I looked at this, time.strptime() leveraged off the platform's
strptime(), which meant it had all the extra features, bugs and
missingness of the platform's implementation. 

We now seem to be using a Python implementation in _strptime.py. This
implementation does Locale's by feeding a magic date to time.strftime()
and figuring out how it formats it.

This revealed that time.strftime() is not honouring the Locale settings,
which is causing the new Python strptime() to also get it wrong.

$ set | grep "^LC\|LANG"
GDM_LANG=en_AU.UTF-8
LANG=en_AU.UTF-8
LANGUAGE=en_AU.UTF-8
LC_COLLATE=C

$ date -d "1999-02-22" +%x
22/02/99

$ python
...
>>> import time
>>> time.strftime("%x", time.strptime("1999-02-22","%Y-%m-%d"))
'02/22/99'

This is consistent across all three platforms for multiple Python
versions, including 2.1 and 1.5 (where they were available) which BTW
don't use the Python implementation of strptime().

This suggests that all three of these platforms have a broken libc
strftime() implementation... but all three? And why does date work?

Can others reproduce this? Have I done something stupid? Is this a bug,
and in what, libc or Python?

Slightly OT, is it wise to use a Python strptime() on platforms that
have a perfectly good one in libc? The Python reverse-engineering of
libc's strftime() output to figure out locale formatting is clever,
but...

I see there have already been bugs submitted about strftime/strptime
non-symmetry for things like support of extensions. There has also been
a bug against strptime() Locale switching not working because of caching
Locale formatting info from the strftime() analysis, but I can't seem to
get non-C Locale's working at all...

-- 
Donovan Baarda <abo at minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/