+972 52-548-6969
Non overlapping time periods–because I like the pain of 2 AM wakeup calls
This post is partly in response for this post, discussing the Azure problem with leap year. But it is actually a bit more general than that.
In my code, here is how I define “one year from now”:
DateTime.Today.AddYears(1).AddDays(3);
As it turned out, this tend to have a lot of implications on your business, most of them are actually pretty good ones.
For a start, you will never get hit with a leap year bug, but more importantly, you are never going to have to deal with an immediate cutoff. This is important because it gives you time. Mostly, it gives you time to screw up, but having the time to do so without having an egg all of your face is a really nice thing.
For example, all of our subscriptions are using a similar method of calculation, and this is why we can take the ordering system down for a few hours or even a day or two and no one will actually notice. We have a big grace period in which we can work things out.
Sure, a user gets 3 “extra” days for free out of this, but frankly, I don’t give a damn. It is more important that I get the buffer, and most users like it much better when you don’t slam the doors in their faces on the first chance.
One of the things that is important is style, and giving a grace period for those sort of things is crucial.
Comments
Makes no difference if you don't remind them to renew the subscription earlier. You could give a month instead of 3 days and people would still phone you at 2 am with symptoms of a sudden license expiration Some ideas: 1. never expire licenses at night 2. my ISP has a nice solution for domain registration - the website is taken down as soon as the registration period ends but I can re-enable it immediately through an automated web interface - 'give me 3 extra days NOW and I'll pay during that time'
I don't understand how this prevents sudden cutoffs. Regardless if you use AddYears(1) and AddYears(1).AddDays(3) you still have to have some way for them to get notice in advance, and if the billing system goes down on that 1 year day 3 then they will notice.
Rafal: Never expire licenses at night where? Should we time them to expire when it's most convenient in our timezone? Most likely, a user will notice it first thing in their morning anyway.
Either way, I think Ayende means that the extra three days bit is so that the users have time to fix this even if they've set up an annual charge (and saw the emails and decided to fix it when needed), and the ordering system was down for a while when they needed the new license.
@Rafal, just look at domain purchaise model, there is 14 days "window" alfter expiration time
A grace period for license enforcement is fine, but this isn't a good general purpose solution to time ranges. Some periodic time ranges must be non overlapping. If you simply give each period a few days grace, you end up with a few days overlap. In which time period did the events during that overlap take place? Sometimes this is an important question.
I prefer the solution of exclusive end dates. The end date of the range is not the last day that it is effective, but the first day that it is no longer effective. This coincides with the start date of the next range. It guarantees no overlaps and no gaps. And as an added bonus, you only need to store one date per period.
start <= today < end
Comment preview