CiviCRM Community Forums (archive)

It appears that the recalculation of Membership Status, both by the membership form and the 'Update Membership Statuses' scheduled job, are faulty when the Offset for a change of status is 'month'.

Consider a membership that falls from Current to Grace at the end of the year (Dec 31st) and should expire at the end of the following February. The obvious way to define this in the Membership Status Rules is to set with the following relative priorities:
- Current: End Event = 'end date'
- Grace:    Start Event = 'end date'; End Event = 'end date' + 2 months.
- Expired: Start Event = 'end date'
But the system appears to calculate the end of Grace as Dec 31st + 2 months = Feb 31st = Mar 3rd. So the change of status to Expired occurs several days late.

My tested workaround is to change one rule:
- Grace: Start Event = 'end date'; End Event = 'end date' + 59 days. The change of status will be out by only one day each Leap Year but correct in other years.

Only status changes governed by the length of February cause inaccuracies greater than one day (I think).
To fix it properly would require the offset calculation to take account of month ends, including leap years.

Is my assessment correct? I've not checked the code.
Has this been fixed in a later version? I have looked but cannot find anything in JIRA up to 4.5.
Is this worth a bug report or just a note accompanied by this workaround?

David

CiviCRM 4.4.3