Details
Bug
Blocker
Description
Prorated dates in the future are calculated using "+1 month", but that can cause January 30 and 31 to forward to March rather than February. This incorrect date is then used for renew dates and invoice line items for prorated services.
Activity
I don't see an issue with the current fix. Can you provide a case that would be invalid?
In the case that today is < pro rata day, the prorate date will remain in the current month. This fix sets the date to the first of the current month, but still continues to format the date to the pro rata day anyway.
e.g.
start day: January 31
pro rata day: 1
return value: February 1 (instead of March 3 due to the fix)
start day: February 2
pro rata day: 10
return value: February 10 (only prorated 7-8 days in the future)
Tyson Phillips (Inactive)
added a comment - I don't see an issue with the current fix. Can you provide a case that would be invalid?
In the case that today is < pro rata day, the prorate date will remain in the current month. This fix sets the date to the first of the current month, but still continues to format the date to the pro rata day anyway.
e.g.
start day: January 31
pro rata day: 1
return value: February 1 (instead of March 3 due to the fix)
start day: February 2
pro rata day: 10
return value: February 10 (only prorated 7-8 days in the future) Scanning through it again, it looks ok.
Cody Phillips (Inactive)
added a comment - Scanning through it again, it looks ok. 
I think the current fix fails to take into consideration the case where today is < pro rata day. In that case, the value returned by Packages::getProrateDate(), I believe, is invalid since that is now based off the first of the month.