3 ms·
with #2 you have an issue with days of 29-31 due to uneven months. so if someone would subscribe on 29th of january, then it would mean the next payment would b
by hknmtt 4y ago
with #2 you have an issue with days of 29-31 due to uneven months. so if someone would subscribe on 29th of january, then it would mean the next payment would be on 1st march and it throws off the entire thing from there on. same for 31th march and april having only 30 days. so some people would get those shifting dates anyway. i could make it so that 29-31 are forbidden and it would move forward to 1st and then there is no problem from the get go, the user just gets couple of free days - BUT i have to handle it in the logic so it will give the user access(technically the access is not valid just yet). the other way round would be to move it backwards to 28th but then the user did not receive the access in case it is 30th, for example. hence why i am inclined to go with #1.
- gnicholas 4y agoIt doesn't throw things off for future payments — it just makes it so that on short months the payment is taken slightly earlier/later. This is presumably not a core part of your business, and you're spending a lot of time thinking about it. I would google to see how others have handled this problem and just do what they do. Otherwise you are spending too much time reinventing the wheel for a presumably-ancillary part of your business. If someone subscribes during a short month, they are always billed on that day of the month. If someone subscribes during a month with more than 28 days, they are always billed on that day of the month during months with sufficient days. During months without sufficient days, they are billed on the first of the following month. When that happens, they will be billed twice during the long month and zero times during the preceding short month. No one should mind this. Option 1 will seem identical to most users, but some may notice. Why not give them 31 days though? That way no one can complain.