Bug 1297863 - to account for daylight savings events, dev_sku (CDK) entitlements should add Calendar.DATE units of expires_after to establish the subscription end date
to account for daylight savings events, dev_sku (CDK) entitlements should add...
Status: VERIFIED
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
1.2
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: William Poteat
Katello QA List
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-12 11:28 EST by John Sefler
Modified: 2016-02-05 17:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)

  None (edit)
Description John Sefler 2016-01-12 11:28:13 EST
Description of problem:

CDK (dev_sku) products have a expires_after attribute which is used to determine the number of days a subscription will endure.  If not present, 90 days was is the default as specified in the design doc https://mojo.redhat.com/docs/DOC-1042464.

Upon testing, I used a java Calendar object and added the expires_after value to predict the end date of the subscription as shown in this code snippet for the default case... 

  String defaultExpiresAfter = "90"; // days
  Calendar expectedEndDate = Calendar.getInstance();
  expectedEndDate.setTimeInMillis(consumerCert.validityNotBefore.getTimeInMillis());
  expectedEndDate.add(Calendar.DATE, Integer.valueOf(defaultExpiresAfter));
  Assert.assertEquals(ConsumerCert.formatDateString(devSkuEntitlement.validityNotAfter), ConsumerCert.formatDateString(expectedEndDate), "When no expires_after attribute exists on the devSku product, the entitlement's validityNotAfter date defaults to '"+defaultExpiresAfter+"' days after the consumer was registered date ("+ConsumerCert.formatDateString(consumerCert.validityNotBefore)+").");


Actual results is failing with this message...
  When no expires_after attribute exists on the devSku product, the entitlement's validityNotAfter date defaults to '90' days after the consumer was registered date (Jan 11 2016 16:38:28 EST). expected:<Apr 10 2016 16:38:28 EDT> but was:<Apr 10 2016 17:38:28 EDT>

Notice that the actual calendar value is 1 hour ahead of the expected (caused by crossing over the daylight saving event to "Spring" forward an hour).  In this case the customer gained an extra entitlement hour and is happy.  If the entitlement duration spanned over the daylight savings event in the Fall, the customer will lose an expected hour of entitlement and be sad. 


It appears that Candlepin is currently adding a duration of milliseconds (equivalent to the expires_after in units of days) which does not account for daylight savings time events.


Version-Release number of selected component (if applicable):
subscription management server: 2.0.10-1
[root@jsefler-f22-candlepin candlepin]# git branch
* master
[root@jsefler-f22-candlepin candlepin]# git log | head -1
commit ec0df8e8aefc812c5fd0e57e7f5f2d131ba4371a
Comment 1 Chris Snyder 2016-02-03 13:27:21 EST
commit 62cb9b9b6a03bf9b8fd837b95138069a0c27d8c8
Author: William Poteat <wpoteat@redhat.com>
Date:   Fri Jan 29 08:44:49 2016 -0500

    1297863: Use calendar for expiry interval


Fix in master as of the above commit.
Comment 2 John Sefler 2016-02-05 17:48:20 EST
Automated testing of version...
subscription management server: 2.0.10-1
[root@jsefler-f22-candlepin candlepin]# git branch
* master
[root@jsefler-f22-candlepin candlepin]# git log | head -1
commit 6781ded6f0e4fab8099191aa5f01c983aa62afeb



Asserted: Actual value of 'Apr 20 2016 16:50:01 EDT' matches expected value: When an expires_after attribute exists on the devSku product, the entitlement's validityNotAfter is '75' days after the consumer was registered date (Feb 5 2016 16:50:01 EST).


Asserted: Actual value of 'May 5 2016 16:53:53 EDT' matches expected value: When no expires_after attribute exists on the devSku product, the entitlement's validityNotAfter date defaults to '90' days after the consumer was registered date (Feb 5 2016 16:53:53 EST).


Automated tests are now passing across the Spring daylight savings event scheduled for Mar 13, 2016.

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