Bug 864569 - Reduce length of date field in All Available Subscriptions tab
Reduce length of date field in All Available Subscriptions tab
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: John Sefler
IDM QE LIST
:
Depends On:
Blocks: 771481 840993
  Show dependency treegraph
 
Reported: 2012-10-09 11:26 EDT by Matt Reid
Modified: 2013-02-21 03:59 EST (History)
3 users (show)

See Also:
Fixed In Version: subscription-manager-1.1.4-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:59:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Shorter Date Field (43.73 KB, image/png)
2012-10-09 11:26 EDT, Matt Reid
no flags Details
verified that the calendar date field is now 10 chars wide (80.31 KB, image/png)
2012-11-16 11:56 EST, John Sefler
no flags Details

  None (edit)
Description Matt Reid 2012-10-09 11:26:05 EDT
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):
subscription-manager-1.1.2-1-git
Comment 1 Matt Reid 2012-10-09 11:26:27 EDT
Created attachment 624154 [details]
Shorter Date Field
Comment 2 Bryan Kearney 2012-10-31 11:25:26 EDT
fixed in master at 1de6ce6b0a0f02b6000621444ebb920c6179741a
Comment 4 Adrian Likins 2012-11-08 17:45:43 EST
commit 1de6ce6b0a0f02b6000621444ebb920c6179741a
Author: Bryan Kearney <bkearney@redhat.com>
Date:   Tue Oct 30 14:56:23 2012 -0400

    864569: Make the date picker widget 10 characters wide
Comment 6 John Sefler 2012-11-16 11:56:14 EST
Created attachment 646452 [details]
verified that the calendar date field is now 10 chars wide

Verifying Version...
[root@rhsm-accept-rhel6 ~]# rpm -q subscription-manager-gui
subscription-manager-gui-1.1.8-1.el6.x86_64

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:
ea0469db2f2eea176e90f54cf3419a6fd6dc74e9
    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
Comment 8 errata-xmlrpc 2013-02-21 03:59:04 EST
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-2013-0350.html

Note You need to log in before you can comment on or make changes to this bug.