Getting the date difference in years months days.

[quote=126481:@Dave S]What? A question was asked… I offered a solution (perhaps not a perfect one)… but not sure where “poison” comes in?

And it is (and always will be) that plugins have there place… and I don’t this this is one of them… When this forum degrades to the point where an opinion is “poison”, then …[/quote]

Ignore him dave

[quote=126572:@Norman Palardy]Counting in days is reasonably precise.
Counting in weeks is also.
Counting in any other units requires some heuristics - and then you get into situations where “well I would have said” vs what someone else would have said.[/quote]

You are right, human beings often have imprecise ways of referring to things. Which incidentally promises a world of misinterpretation for gadgets such as Siri :wink:

Talking about precision, I woke up this morning thinking about the dates Tim picked.

I do not understand. Between 2013/2/20 and 2014/2/5, say at 12 midnight or 24:00 hour for the commodity of the count.

If I count days on my calendar, I will put my finger on each of the days, including 2013/2/21 since the 20th has already elapsed until 2013/2/28 = 7 days. Then on every day from 2014/2/1 to 2014/2/5 = 5 days. That makes 12 days.

I placed on the same application the DateDifferenceMBS example set to these dates, Hamish method and Tim method.

Hamish and Tim methods say 11 months and 16 days.
Christian’s plugin says 11 months and 12 days.

I am sorry, but after counting again on my faithful paper calendar with my little index finger, I find 11 month and 12 days, admitting I will count February 5, 2014 as part of the count. DateDifferenceMBS says the same.

Call me number dyslexic, there is absolutely no way whatever hand or finger I use I can find 16 days.

More interesting, between 2012/2/20 and 2013/2/5, same 12 midnight/ 24:00 hour. Counting with my fingers on my faithful paper calendars pages, I find 13 days, since 2012 being a leap year, February has 29 days.

How is it MBS still finds 12 and other methods 16 ?

As Norman pointed out, human beings sometimes have strange ways of counting, but in this instance, something tells me the computer is wrong…

Does it have anything to do with DST? Daylight saving time?
This site counts it to 11 months 16 days: http://www.convertunits.com/dates/from/Feb+20,+2013/to/Feb+5,+2014
Is 11 months and 12 days correct? :slight_smile:

It depends on whether you count the months first. Starting from 2013-02-20, you go 11 months to arrive at 2014-01-20, then you start counting days. 11 to 2014-01-31 plus 5 more, for a total of 16 days. You count the larger units before the smaller.

[quote=126582:@Albin Kiland]Does it have anything to do with DST? Daylight saving time?
This site counts it to 11 months 16 days: Number of days between February 20th, 2013 and February 5th, 2014
Is 11 months and 12 days correct? :)[/quote]

DST is one hour, and it happens at 2:00 AM. It could not leap a day.

But Tim explains it :

OK. I see. Could be a cultural difference. In Europe, we tend to count in Calendar dates. You are using Rolling dates. Could also be the consequence of a shift in tool paradigm. A physical calendar lends to counting days first and months next.

We are both right, it is one of these cases pointed out by Norman where human beings perception plays a role.

Now the big issue is to find out what is the most intuitive for a UI :wink:

Very interesting indeed :slight_smile:

Coming to think of it, the business usage is less counting in days than in weeks and working days. And corporate month has 30 days. And quarters are counted calendarwise…

Depends what the counting is for I suppose. Cannot help but feel I prefer Calendar…

Oh well :stuck_out_tongue:

So in this case, MBS has it wrong. ;)

[quote=126840:@Tim Hare]
So in this case, MBS has it wrong. :wink:
[/quote]

No. I do not think so. MBS does it like a human being would count. Calendar days. For a human being, a month starts on the first.

You think too much like a computer, Tim.

Yet, MBS has it wrong on leap years…

Could you email me the test project?
where DateDifferenceMBS is wrong?

[quote=126867:@Christian Schmitz]Could you email me the test project?
where DateDifferenceMBS is wrong?[/quote]

I just sent you the project. Between 2012/2/20 and 2013/2/5 DateDifferenceMBS finds 12 days when on a calendar there are 13.

For me, it works.
Make sure you have same time on both dates, because else you have 12 days and a few hours.

[quote=126905:@Christian Schmitz]For me, it works.
Make sure you have same time on both dates, because else you have 12 days and a few hours.[/quote]

You are right. I had not set the hours. Sorry for the false alert. Thank you.

Tim, I wanted to write that there was a mistake in your first code but you corrected it.
I would also add a test if d1 > d2 , if not, invert the two dates and return a negative sign “-” at the beginning of the returned answer.

I wrote that code but I can’t find it. I wasn’t with Xojo, not with Excel, maybe with AppleScript ?

I think it’s not because a member answer a free solution that he isn’t responsible of his code. Then if he answered a wrong solution, he should pay (fined).
(I’m kidding of course) :slight_smile:

Tim, I found, I made that function with Excel. I think there is a trouble in your code. Because February may have 28 or 29 days, and the other months 30 or 31 days.

Thomas, what you are writing is because like me and Christian, you could be looking at the problem with human eyes using a calendar :

  • Count the days until the end of the month
  • Count the months
  • Count the days from the beginning of the month until the ending date

Tim’s method proceeds by counting months from date to date :

  • Count the number of months from February 20, 2013, until January 20, 2014
  • Count the days from January 20, 2014 until February 5, 2014

The human way of proceeding takes into account the length of February, so between 2013 and 2014 finds 11 months 12 days, and between 2012 and 2013, since 2012 is a leap year, february has 29 days, a human being will find 11 months 13 days. That is the result TimeDifferenceMBS will provide. Maybe your method as well.

Tim’s approach works well no matter the length of the month, even in case of leap years, because no month is shorter than 29 days, even if the first date was on 02/29. But he has to test if the first date is on the 29,30 or 31, since he could not go from 31 to 31 when a month has only 28 or 30 days. As you have perfectly well spotted it. His method in my view poses a problem, since it reports results quite different from the calendar approach. 16 days instead of 12.

This computer logic approach does not feel right to me. I tend to believe the best user interface is that which emulates as closely as possible the human ways of doing things.

Dates are SOOOOOOO much fun :stuck_out_tongue:

Maybe you guys need some Unit Tests to check your results!

With all due respect, Michel, I believe my approach does emulate the way most people would count the days, including the OP, all the examples I looked at on the internet, and microsoft excel.