work around for time.strptime(today.strftime("%x"), "%x") failing in some locales

Trying to display a localized date string in a text gui widget. The approach I am taking at the moment is to display the localized string with datetime.datetime.strftime("%x") into a text widget, so that a user can edit it. Then I try to parse the string with time.strptime("x").

The current problem is that for some locales (or_IN, ja_JP.UTF-8, ko_KO.UTF-8) time.strptime("x") can't parse the format generated by datetime.datetime.strftime("%x"). It always throws a ValueError trying to parse this.

I suspect this is a problem with strptime and date strings that use doublebyte seperators in the date format. It could also be an issue with differences in what %x means for strftime and strptime (if I understand correctly, one is basically just the glibc implementation, while the other is python specific).

I'm looking for a better approach to handling localized date strings, so that they can be edited in the ui.

#!/usr/bin/python


# We are trying to present a localized date in a text widget, so
# that a user could potentially edit it, and then we try to
# parse it with datetime.strptime

# however, even if the user doesn't edit the date produced
# by today.strftime("%x"), time.strptime(DATE, "%x") fails
# to parse it

# Not sure what's going on there before. I've seen this once
# before with in_OR, and that turned out to be a locale bug
# in glibc. This could also be the case, so what I'm looking
# for is a more robust approach to this problem that will
# work on all locales

# platform: fedora 14, x86_64
# Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
# [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2

import datetime
import time
import locale

today = datetime.date.today()

# works for "C"
locale.setlocale(locale.LC_ALL, 'C')
print time.strptime(today.strftime("%x"), "%x")

# works for en_us.utf8
locale.setlocale(locale.LC_ALL, 'en_US.utf8')
print time.strptime(today.strftime("%x"), "%x")


# fails for 'ja_JP.UTF-8'
loc = 'ja_JP.UTF-8'
locale.setlocale(locale.LC_ALL,loc)
try:
    print today.strftime("%x")
    print time.strptime(today.strftime("%x"), "%x")
except ValueError:
    print "failed for %s" % loc


loc = 'ko_KR.UTF-8'
locale.setlocale(locale.LC_ALL,loc)
try:
    print today.strftime("%x")
    print time.strptime(today.strftime("%x"), "%x")
except ValueError:
    print "failed for %s" % loc

And a sample output of this test program on my system (fedora 14, x86_64):

time.struct_time(tm_year=2011, tm_mon=10, tm_md开发者_运维问答ay=10, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=283, tm_isdst=-1)
time.struct_time(tm_year=2011, tm_mon=10, tm_mday=10, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=283, tm_isdst=-1)
2011年10月10日
failed for ja_JP.UTF-8
2011년 10월 10일
failed for ko_KR.UTF-8

---

Check whether you have your locales in locale_alias dictionary

>>> import locale
>>> len(locale.locale_alias)
843
>>> locale.locale_alias.keys()[:10]
['ko_kr.euc', 'is_is', 'ja_jp.mscode', 'kw_gb@euro', 'yi_us.cp1255', 'ca_es@euro', 'ja_jp.ujis', 'ar_ma', 'greek.iso88597', 'sr_yu.iso88592']
>>>

---

Use your toolkit's date widget instead of a text widget. All major toolkits have a date widget that just works, and is much easier to edit than a textfield with whatever date representation.

---

Eventually, just changed the text entry for the date to use iso date format, ala: 2013-12-31. It's a little jarring in a otherwise lovely localized ui, but alas.

In this particular case, the native toolkit did not provide a text based date entry, and usage scenario makes searching on dates far in the future common (meaning dozens of clicks in the gui calendar widget).

Other similar variations of this problem also led to that change. For a few locales, particularly locales that used a date format with month titles that would change from a single glyph to a two char name, the built in python strptime would fail, even with the correct locale, and an otherwise correctly formatted strings. For bonus aggravation, in some locales, it would only fail if the month > 10, so it would work except for nov/dec. For other locales, it was the glibc strptime that would fail. Filed bugs for both cases exist upstream.