Davethe user code base had this function in it:
public DateTime GetBeginDate(DateTime dateTime)
return new DateTime(dateTime.Year, dateTime.Month, 01).AddMonths(1);
I have some objections to the naming here, which could be clearer, but this code is fine and implements their business rule.
When a customer subscribes, their real the subscription date begins on the first of the following month, for billing purposes. Note that it is passed in datetime as subscriptions can be set to start in the future or in the past, with the billing date always tied to the first of the following month.
One day this all worked fine. After implementation, subscriptions started ignoring all of this and always started on the date someone entered the subscription information.
One of the commits in the release described the change:
Adjusted the start dates for subscriptions to the beginning of the current month instead of the beginning of the next month so that people who order SVC will have access to the SVC website when the group closes.
This sounds like a very reasonable business process change. Let’s see how they implemented it:
public DateTime GetBeginDate(DateTime dateTime)
return DateTime.Now;
It is not what commit claims is happening. This just ignores the date provided and just sets each subscription to start at this point. And it doesn’t bind to the start of the month, which is not only different from what the commit says, but also throws off their billing system and a bunch of notification modules that all assume subscriptions start on the first of the month.
The rectify the change would be simply to remove AddMonths call. If you’re new here, you might wonder how such an obvious mistake made it past testing and code review, and the answer is simple: they did none of those things.