Bug 883486 - the local time's start/end dates rendered in the list --available/--consumed may be wrong during daylight savings
Summary: the local time's start/end dates rendered in the list --available/--consumed ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 7.0
Assignee: William Poteat
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: rhsm-rhel70
TreeView+ depends on / blocked
 
Reported: 2012-12-04 17:27 UTC by John Sefler
Modified: 2014-06-18 00:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 13:01:24 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description John Sefler 2012-12-04 17:27:23 UTC
Description of problem:
When subscription manager reports a start/end time in the list of consumed/available/installed, I'm afraid the conversion calculation to the system's local time is wrong when the span from the current system's date to the start/end date of the entitlement spans across a change in daylight savings time.
Observe the example below... 

Version-Release number of selected component (if applicable):
[root@jsefler-6 ~]# rpm -q subscription-manager
subscription-manager-1.1.10-1.el6.x86_64

How reproducible:


Steps to Reproduce:
1. On my system I have an entitlement granted from candlepin with the following Vailidity start date:
[root@jsefler-6 ~]# openssl x509 -text -in /etc/pki/entitlement/1514866654591212162.pem | grep Validity -A1
        Validity
            Not Before: Oct 16 04:00:00 2012 GMT

2. Using a trusted time converter to see what Oct 16 04:00:00 2012 GMT really is on my system located in Raleigh/Eastern time zone where daylight savings time is practiced, it converts to...
http://www.timeanddate.com/worldclock/converted.html?iso=20121016T04&p1=211&p2=207&p3=&p4=&p5=&p6=&p7=&p8=&p9=&p10=&p11=&p12=

Oct 16 00:00:00 2012 EDT  <====  WE WILL USE THIS AS OUR EXPECTED RESULT

3. Now let's see what subscription-manager list --consumed displays when the system's date is Oct 1, 2012
[root@jsefler-6 ~]# date 100100002012
Mon Oct  1 00:00:00 EDT 2012
[root@jsefler-6 ~]# subscription-manager list --consumed | grep Starts:
Starts:                 10/16/2012
                        ^^^^^^^^^^
                        LOOKS GREAT!

4. Now let's see what subscription-manager list --consumed displays when the system's date is Dec 1, 2012
[root@jsefler-6 ~]# date 120100002012
Sat Dec  1 00:00:00 EST 2012
[root@jsefler-6 ~]# subscription-manager list --consumed | grep Starts:
Starts:                 10/15/2012
                        ^^^^^^^^^^
                        LOOKS WRONG!


THIS IS A GOOD REASON WHY I PERSONALLY THINK THE DATE FORMATS IN SUBSCRIPTION MANAGER LISTINGS SHOULD SHOW MORE SIGNIFICANT FIGURES THAN THE DAY.

This particular case only affects customers who like to reflect on "what could have been." I'm sure if we do the same test on the validity end date across a time span straddling the Spring time when we convert back to standard time, we'll see a similar flip of the end date.

Comment 1 Chris Duryee 2012-12-04 19:28:26 UTC
More info:

It looks like formatDate() in managerlib.py is passing in LocalTz to strftime. LocalTz needs to calculate the DST application based on the date passed in, and not the current date.

Comment 5 William Poteat 2014-01-29 12:54:01 UTC
master commit 77a069783bb6a0f83506ba766b4f7ed29f06d4b0

Comment 7 John Sefler 2014-02-11 18:04:00 UTC
Verifying version...
[root@jsefler-7 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.3-1
subscription-manager: 1.10.13-1.el7
python-rhsm: 1.10.12-1.el7


1. On my system I have an entitlement granted from candlepin with the following Vailidity start date:
[root@jsefler-7 ~]# openssl x509 -text -in /etc/pki/entitlement/5996599669812319957.pem | grep Validity -A1
        Validity
            Not Before: Feb  7 00:00:00 2014 GMT

2. Using a trusted time converter to see what Feb  7 00:00:00 2014 GMT corresponds to on my system located in Raleigh/Eastern time zone where daylight savings time is practiced, it converts to...
http://www.timeanddate.com/worldclock/converted.html?iso=20140207T00&p1=0&p2=207

Feb 6 19:00:00 2014 EST  <====  WE WILL USE THIS AS OUR EXPECTED RESULT

3. Now let's see what subscription-manager list --consumed displays when the system's date is Feb 1, 2014 (EST)
[root@jsefler-7 ~]# date 020100002014
Sat Feb  1 00:00:00 EST 2014
[root@jsefler-7 ~]# subscription-manager list --consumed | grep Starts:
Starts:            02/06/2014
                   ^^^^^^^^^^
                   LOOKS GREAT!


4. Now let's test what subscription-manager list --consumed displays when the system's date is fast forwarded across the Daylight Savings Spring 2014 date to Apr 1, 2014 (EDT)

[root@jsefler-7 ~]# date 040100002014
Tue Apr  1 00:00:00 EDT 2014
[root@jsefler-7 ~]# subscription-manager list --consumed | grep Starts:
Starts:            02/06/2014
                   ^^^^^^^^^^
                   VERIFIED! After crossing daylight savings time, the entitlement start date is correctly rendered


5. Finally let's test what subscription-manager list --consumed displays when the system's date is rewound across the Daylight Savings Fall 2013 date to Oct 1, 2013 (EDT)
[root@jsefler-7 ~]# date 010100002013
Tue Jan  1 00:00:00 EST 2013
[root@jsefler-7 ~]# subscription-manager list --consumed | grep Starts:
Starts:            02/06/2014
                   ^^^^^^^^^^
                   VERIFIED! After crossing daylight savings time again, the entitlement start date is correctly rendered

Comment 8 Ludek Smid 2014-06-13 13:01:24 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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