"JE McGimpsey" wrote in message
...
In article ,
"Peo Sjoblom" wrote:

and that is the error in DATEDIF

Rather than an error in DATEDIF, which works very consistently, if not
always the way we want it to), it's inherent in *any* deterministic
algorithm that I've ever seen used.


true, I should have expressed myself better.

"Month", as a unit of time, is just too fluid a concept to be captured
algorithmically.

For instance, using Rick's definition, 1 March is 1 month and 0 days
after 31 January. One way of interpreting that is that 1 March is also 1
month and 0 days after 28 January, 29 January, and 30 January. That way
leads to madness when one wants a single result when trying to calculate
a date 1 month prior to 1 March.

That definition also causes strangeness when the first month is shorter
than the final one:

Start Date End Date Months/Days
28 Feb 28 Mar 0/28?
28 Feb 29 Mar 0/29? or 1/1?
28 Feb 30 Mar 0/30? or 1/2?
28 Feb 31 Mar 0/31? or 1/3?
28 Feb 1 Apr 1/0? or 1/4?
01 Mar 01 Apr 0/30? or 1/0?

in either case there's a discontinuity in the function...

Those of us who've been around here a while may remember herculean
efforts lead by Norman Harker to better DATEDIF with a self-consistent
algorithm, and the frustration of not being able to do so.


Yes I remember that



--

Regards,

Peo Sjoblom