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.