I was playing with a date difference calculator in C (because... SO raisins), and checking my work against timeanddate.com, but I think that website is in error. Here are two test cases:

https://www.timeanddate.com/date/durationresult.html?m1=2&d1=2&y1=2000&m2=2&d2=1&y2=2001

https://www.timeanddate.com/date/durationresult.html?m1=2&d1=2&y1=2001&m2=2&d2=1&y2=2002

Anyone else think that looks wrong? It should be:


Why? Because February doesn’t have 30 days, and because 2000 is a leap year.

Tell me I’m not making a dumb mistake here.

[edit] Sorry, dates listed in DAY-MONTH-YEAR format.

Both of you are right. Everybody gets a prize!

2000 is a leap year - i.e. 366 days - the date includes 28 February, otherwise 365.
2001 is not a leap year - i.e. 365 days whether or not February is included.

So you have to make sure what the start and end times mean and whether you are counting elapsed time, included time, ... the number of 24 hour periods, or crosses on a calendar ... and what inclusive means for that matter.

Calculating all that as months and weeks is even more nebulous. To be fair though weeks are always 7 days.

I think I see what they do there:
* 2-2-2000 to 2-3-2000 is one month
* 2-3-2000 to 2-4-2000 is one month
...
* 2-1-2001 to 2-2-2001 is 30 days

Measuring months is always going to be a problem, for obvious reasons. IMO, ideally if
d1 = days_diff(x, y)
d2 = months_and_days_diff(x, y)
then if I do
a = z + d2
then days_diff(z, a) = d1 should be true for all values of x, y, and z. But if it's not true that for any integer n
months_and_days_diff(x, y) = months_and_days_diff(x + n, y + n)
then this will not hold. I'm not sure in what context where one is trying to compare time intervals consistently to the day one would use months and days instead of just total days, though. For most people after 60 days it would be accurate enough to divide by 30 and ignore the fractional part.

Obtaining the difference between dates in anything other than number of days is fraught with issues - not least of which is to agree what 'constitutes a month' when the start and end dates don't exactly fall on the start/end of a month. When I was involved with this sort of thing a while ago, we dealt in whole calender months with the number of days the sum of the extra days before/after a complete month. However I've known a fixed number of days (I've seen 30.5) set for a month etc etc. for a simple division...

From 2 Feb 2000 (included) to 1 Feb 2001 (excluded) by whole month metric is:

28 days in Feb 2000
11 months from March 2000 to Jan 2001


From 2 Feb 2001 (included) to 1 Feb 2002 (excluded) by whole month metric is:

27 days in Feb 2001
11 months from March 2001 to Jan 2001

The way I see it is this: A full month makes no sense outside of its defined boundaries.
How many months between 4 January and 4 February?

Zero. January is a month. February is a month. January-February is not a month.

So how many days remains is (days remaining in January inclusive + days from February exclusive).
(The exclusivity there is not required, as you may wish to include the final day in your count. I have not been.)

January is 31 days long, so 32-4 = 28.
Add 4-1 days from February to get 31 days. (Or +4 = 32 days if you want to count 4 February.)

To simply say that 30.5 days or something counts as a “month” is stupid to me, as there is no “number of days in a month”.

Hence:

2 February 2000 to 29 February 2000 (leap year!) is 28 days
+ 1 February 2001 - 1 is 0 days
= 28 days.
(29 days if we wish to include 1 February 2001.)


To consider the point further, what if I had asked about 2 February 2000 to 7 August 2001? Is February-nothing-in-between-August a month? Of course not. What about February-March, March-April, April-May, May-June, June-July, July-August?

Exactly. We are getting stupid because we cannot assume any specific number of days between two calendar dates involving months, because a “month” does not have a specific number of days. April has a specific number of days. August has a specific number of days. Etc.

Thus my position is: don’t count a day towards a months unless you are also counting all the other days in that month.

This aligns much more with reality to me than other metrics, like the one used by timeanddate.com. I want the actual number of days outside of whole months that have passed.

I want the actual number of days outside of whole months that have passed.

Hmm... So wouldn't that mean that from 2020-03-02 to 2020-04-30 (exclusive) there are 0 months + 59 days? If a month only counts if it appears whole in the interval, it would appear that way. While I agree that this criterion is internally consistent, this is not how anyone measures time.

If you think about it, years have the exact same problem as months, since not all years are the same length. Yet if you were born on January 2nd, on your first birthday you are not said to be zero years and 365 days old simply because you have not lived through any whole calendar year.
Incidentally, when I was little I was asked to choose on which of the two possible dates I wanted to celebrate my birthday most years.

Still hinges on inclusivity and calendars. (Gets even worse if midnight and hh::mm times come into play.)

@helios

...exactly! The inconsistency of days to months to years is where people get hung up.

And, after posting my rant version, I realized that I too consider it to have been a month ago on today’s date last month...

so reality and I currently disagree, and I am unsure how to solve my conundrum.


(I’m clearly a newbie at thinking about this, LOL.)

The problem is a simple case of semantics. 'between', 'month', 'year' etc need to be defined clearly.

Its funny, I was just thinking about monthly payments as I was driving home today. I was thinking how many places bill the same day each month.

Got me thinking that if someone gets paid every 2 weeks but is billed the same day every month, eventually they may end up in a situation where the bill comes sooner than their paycheck.

https://i.etsystatic.com/16458226/r/il/619bae/2378902853/il_794xN.2378902853_as43.jpg

Well, yes, it should happen once or twice a year, I'd expect.

I find it interesting no one has mentions leap seconds either. With larger datetime gaps those seconds can add up, so you may end up having to take them into account as well if you're going for a precise calculation. This could be the difference of a whole day if your date/times start or end at midnight.

Leap seconds are only relevant if
1. you're measuring the interval in seconds between two events,
2. you're doing it using the {wall|GPS|atomic} clock timestamps of the two events (rather than some uniform oscillator for example), and
3. it's very important to get the interval exactly right.
Most processes fail at least one of these conditions. For ordinary date calculations, assuming the Gregorian calendar without leap seconds is good enough.