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
commit 62cb9b9b6a03bf9b8fd837b95138069a0c27d8c8 Author: William Poteat <wpoteat> Date: Fri Jan 29 08:44:49 2016 -0500 1297863: Use calendar for expiry interval Fix in master as of the above commit.
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.