Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionKenichi Takemura
2011-10-07 08:17:40 UTC
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:
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.
(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?
Comment 20Kenichi Takemura
2011-10-18 01:33:30 UTC
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