Bug 883486
| Summary: | the local time's start/end dates rendered in the list --available/--consumed may be wrong during daylight savings | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | John Sefler <jsefler> |
| Component: | subscription-manager | Assignee: | William Poteat <wpoteat> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | alikins, bkearney, cduryee, ckozak, jgalipea, tlavigne, wpoteat |
| Target Milestone: | rc | ||
| Target Release: | 7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 13:01:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 863175 | ||
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. master commit 77a069783bb6a0f83506ba766b4f7ed29f06d4b0 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
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. |
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.