Red Hat Bugzilla – Bug 864569
Reduce length of date field in All Available Subscriptions tab
Last modified: 2013-02-21 03:59:04 EST
Description of problem:
In our current date field, we can show enough characters to display the current date, 2012-10-09, but then we have room for ~5 more characters.
Assuming numbers take up the same amount of space, irrespective of language, having the ability to display 2012-10-09-2012 doesn't do us a whole lot of good. I'd rather we just cut ~4 characters out of the field and show the date like we currently do, but with a bit of padding on the right edge, and free up some whitespace/extra room for other languages to flex things around.
Doing this will significantly increase the whitespace we have in the middle, from ~40px to ~74px.
Version-Release number of selected component (if applicable):
Created attachment 624154 [details]
Shorter Date Field
fixed in master at 1de6ce6b0a0f02b6000621444ebb920c6179741a
Author: Bryan Kearney <email@example.com>
Date: Tue Oct 30 14:56:23 2012 -0400
864569: Make the date picker widget 10 characters wide
Created attachment 646452 [details]
verified that the calendar date field is now 10 chars wide
[root@rhsm-accept-rhel6 ~]# rpm -q subscription-manager-gui
Note: Originally the calendar date field was localized and the width of the date field was 14 chars for the pleasure of viewing all localized dates. Currently the date field is no longer localized due to hardships. Therefore the 10 char wide field is now a good choice.
For reference, here is the commit to ISO8601 dates:
Use ISO8601 date format in allsubs tab
Previously we were using the localized date
format (ala, strftime('%s')) which is lovely,
but is more or less impossible to parse, even
by the tools that claim to (for ex, strptime('%x')).
We had worked around this in a few cases, by
falling back to en_GB localized date format,
but that was pretty much just a kluge. For
bonus fun, some of the dates would only
fail to parse on double digit months. Or for
some locales, specific months that had
unicode char's the date parser didn't like.
In addition, strptime() is especially broken
on python 2.4 available on RHEL 5 and earlier.
So, enough of that. ISO8601 dates it is.
- remove locale kluge
- remove unit tests specifically for that kluge
- add test cases for widgets.DatePicker
Moving to VERIFIED
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.