I am trying to make an algorithm that counts the days between two dates, e.g. between 3/1/2012 and 3/2/2012.
What is the correct answer, or the most popular choice? Should be the one I use?
In this case, if I don't include both dates I am comparing, the days are 0; if I include one of them, the days are 1; if I include both, the days are 2.
First what would make sense in your application if both dates were the same day? In my opinion the obvious answer is 0 and if that's your answer as well then the logical conclusion is to map dates that differ by one day to 1 and not 2. If you map dates that differ by a day to 2 then you have a gap and there is no way to map dates that don't coincide to 1. From a mathematical perspective things feel more consistent if there are no gaps.
I would answer 1 because they are one day apart. There isn't a right answer to this though. It depends on the requirements for what you want to accomplish.
I think it is a question of terminology and context.
If days between excludes the bounds, then the days between the two dates would be 0. Whereever this may be needed.
Date difference, i.e. how many days do I need to add to the start date to reach the end date: 1.
Or a date interval, including the bounds, e.g. how many leave days do I have from a start to an end date? Here the answer is 2.
I think the crux of the dilemma is that you've named the operation "calculating how many days between two dates". Clearly there are zero days between 3/1/12 and 3/2/12, but that more likely means that you've named the calculation wrong rather than done the wrong calculation.
Date arithmetic is notoriously tricky because of all the exceptions, so you really have to be rigorous in defining your requirements. For example, what does "now minus one day" translate into? You might say it means whatever time it was 24 hours ago, but I think that would be wrong in most applications. True, most days have 24 hours, but with daylight saving time one day has 23 hours and one day has 25 hours. I thank if it is noon on Sunday then now minus one day means noon on Saturday regardless of how many hours ago that was. I could go on with leap seconds and all the trouble they bring, as well as ensuring all the arithmetic identities and properties hold, but all of this is probably more work than you want to do.
Generally, when doing calendar date arithmetic people are interested in the "difference between dates". You can visualize this by imagining a paper calendar with the dates printed on it and putting a coin or stone or other marker on the starting date. If you are only allowed to move the marker to the immediately following date, how many moves would it take you to get to the ending date? That is the difference between the two dates in days.
One other practical consideration, though, is whether your application really includes the end date. It is typical for insurance contracts, for example, to not include the end date. Policies expire at 12:01 am on the end date. If you buy a policy that expires tomorrow, it's good for less than a day. On the other hand, in California, a "3 day notice to pay rent or quit" eviction notice gives you more than 3 days to get out. You have until the end of the third business day after the notice is served to pay the rent. So Wednesday + 3 days is actually Monday unless Monday is a holiday, in which case it is Tuesday and either way you get the whole final day, so a landlord cannot proceed until today > Wednesday + 3 days, i.e Tuesday or Wednesday. So it's not a straightforward calculation.
The good news is that because it comes up so often, there are libraries you can use to do the calculations and real life situations have reasonably well defined how they want date calculations done in order to clear up just these sorts of confusions.
So you really need to do your homework and correctly specify what interval you are talking about.
Both Dates, because that is what the users expect (in most cases)
I have worked on a few projects that had to work with logic surrounding dates, and expiration of entities. And there are some pitfalls.
The nature of those pitfalls is that what makes sense to a programmer isn't necessarily what makes sense to the people using the application.
People in the business would normally say stuff like, this thing is active from the 1. to the 31. of July. Now what they mean is that both dates are are included, i.e. it should be active for 31 days, not 30. But that defies normal arithmetic rules.
So if you take the question from the end users point of view, then in my experience the answer should be that you need to include both dates when calculating the number of days.
A few examples from my work experience:
I worked at creating an online job board, and we had plenty of problems with end dates for some entity types (expiration for a job, a subscription, etc). These would be specified as the last day this entity was still valid, which is what got stored in the database. But what made sense in the code would be to have the exact time when the entity would change state, i.e. at 00:00 the following date. That lead to very complex domain logic.
At some point, I refactored the entire system, adding one day to every EndDate in the database, and then moved the logic to the presentation layer, specifying that the actual date presented to the user should be the day preceding the one in the database. This lead to much, much cleaner domain logic regarding item expiration.
When I did the next project I worked with where date/entity expiration logic was important, I created a specific Date data type to encompass these rules, including overloading comparison operators with the build in DateTime class, arithmetic operators, etc. This lead to even simpler code, as it much better reflected the domain model, and the requirements for the presentation layer to subtract one day from all end days was removed, also removing the risk that someone would forget to implement this.
Ultimately, the correct answer to this is whatever your business requirements state.
However, when dealing with dates and time spans between dates, one generic way of looking at it to assume that any date that is expressed solely as a date (i.e. without a time portion) is to implicitly add 00:00 to the end of the date (midnight).
Now, calculate how many minutes of difference there is between the two date/times. So using your example (and I'm assuming US Date format here), how many minutes to you have to add, one at a time, to 2/1/2012 00:00 before you reach 3/1/2012 00:00 ?
Once you've done that, convert your minutes to hours, then to day (divide by 60, then divide result by 24) and you'll have your number of days between the two dates.
Using this, it turns out there's 1 day between 2/1/2012 00:00 and 3/1/2012 00:00 which seems to be both logical and in accordance with the general thinking of most people here and those who design well used functions in this area (i.e. Java's java.util.Date or .NET's System.DateTime etc.)
You have to consider the context, if my working schedule is from monday to friday my boss will be a bit displeased if I only show up for 4 days.
That's because in this context, monday doesn't only stand for monday but for monday 8:30 and friday stands for friday 17:00.
The number of days ND between one date D1 and another date D2 is such that:
ND = D2 - D1
or:
D1 + ND = D2
It depends a lot on context, but in my opinion the obvious answer is to include 1 of the dates in the count.
Let's assume you count neither. And also let's assume there's an application that uses your algorithm to determine the difference of 2 dates typed by the user. In this case, the difference between 3/1/2012 and 3/2/2012 is 0. Is it then ok for the user to assume that the 2 dates are equal ? Because that's what 0 suggests: no difference between them -->> they're equal. It's probably wrong...
Let's then assume you count both. In this case, the difference will never be less than 2. Are there 2 days between 3/1/2012 and 3/2/2012 ? Certainly not. What about between 3/1/2012 and 3/1/2012 ? Again: no.
Given the fact that you only have dates as input and no time, I would do the algorithm like this:
As I said in the beginning: this ultimately depends on your business requirements.
