Hide Forgot
Description of problem: When starting subscription-manager GUI in localized desktop(such as ja_JP.UTF8) and registering the system, 'Invalid date format' error dialogue always pops-up. This bug almost makes the GUI unusable. Version-Release number of selected component (if applicable): subscription-manager-0.96.13-1.el6.i686 subscription-manager-firstboot-0.96.13-1.el6.i686 subscription-manager-debuginfo-0.95.8-1.el6.i686 subscription-manager-gnome-0.96.13-1.el6.i686 How reproducible: 100% Steps to Reproduce: 1. $ LANG=ja_JP.UTF8 subscription-manager-gui 2. Register the system 3. Click My Subscriptions or Available Subscriptions tabs or Click 'Update' or 'Calendar' Actual results: 'Invalid date format' error comes up. Expected results: No dialogues please since the date is correct(set by default). Additional info:
I can reproduce above bug with following locales only: ja_JP.UTF-8 ko_KR.UTF-8 other Red Hat supported locale, it is working as expected
*** Bug 744362 has been marked as a duplicate of this bug. ***
Tested on subscription-manager-0.96.12-1.el6, also had this issue.
commit c900ff31d099801fdb832801e85730c3a49a88c8 Author: Adrian Likins <alikins> Date: Fri Oct 7 16:03:28 2011 -0400 744136: workaround date parsing problems in some locales work around for bz #744136 and #704069. Basically, we don't seem to be able to parse dates with time.strptime() in some locales, even if the date is exactly the string created by today.strftime("%x"). So we just set LC_TIME to en_GB which we can parse It's not a great fix, but it is a generalized version of the fix we had for in_OR as well. It will prevent the crash, however, it doesn't show a properly localized date string for this case.
Verified it's fixed on subscription-manager-0.96.15-1.el6.x86_64, but it doesn't show a properly localized date string and the calendar is English, please see the screenshot.
Created attachment 527830 [details] subscription-manager-0.96.15-1.el6
For the date format, it's better to keep the format the same as en_US, it's 10/13/2011 or 13/10/2011, but not 13/10/11.
Created attachment 527833 [details] en_US
(In reply to comment #8) > It's not a great fix, but it is a generalized version of the fix we had for > in_OR as well. It will prevent the crash, however, it doesn't show a properly > localized date string for this case. (In reply to comment #14) > Verified it's fixed on subscription-manager-0.96.15-1.el6.x86_64, but it > doesn't show a properly localized date string and the calendar is English, > please see the screenshot. Agreed. Opening bug 746732 to be reviewed again in the future. moving to VERIFIED [root@jsefler-onprem-62server ~]# rpm -q subscription-manager subscription-manager-0.96.15-1.git.2.6c0ad28.el6.x86_64
(In reply to comment #16) > For the date format, it's better to keep the format the same as en_US, it's > 10/13/2011 or 13/10/2011, but not 13/10/11. The fix for this bug from development is a work-around. As such, the chosen work-around locale en_GB is being used for ja_JP ko_KR and or_IN. Therefore all users of these three locales are affected. Can all three locale communities agree that an en_US work-around is better than en_GB?
For ja_JP and ko_KR, en_US(mm/dd/yyyy hopefully than dd/mm/yyyy) is preferable. Sorry but not sure about or_IN. > > The fix for this bug from development is a work-around. As such, the chosen > work-around locale en_GB is being used for ja_JP ko_KR and or_IN. Therefore > all users of these three locales are affected. Can all three locale > communities agree that an en_US work-around is better than en_GB?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1695.html