MrProgrammer wrote:...AOO provides functions for an exact calculation: 1 month and 1 day.

My criticism may be seen as fundamental and re-critisized therefore, but it concerned some

tangible points:

- Taken as a duration the result is misleading. It cannot tell how long the months were (28<=MonthLength<=31).

- The missing information cannot be retrieved

from the result for further calculations.

- The question was seeking a

formatted result, but

- -

obtained result is generic text. It cannot be referred to as a number. (Resorting to original

Start and

End needed.)

- If

any further evaluation is intended the numbers of years, months, and days need to be extracted.

- The formula given by Zizi64 (for LibO with DATEDIF) will not return what the questioner expects in special cases.

- - This specifically if two related cases are compared. Example:

- - - With

Start=2019-02-28 and

End=2020-03-01 it returns "1 Years 0 Months 2 Days".

- - - With

Start=2019-02-28 and

End=2021-03-01 it returns "2 Years 0 Months 1 Days".

- - - Why? Isn't the second span "exactly" on year longer than the first one?

- - - (It's the same with the formula from chapter D of the linked tutorial.)

- - - Yes. I know the reason, and my example doesn't try to hide it.

- Treating unwanted effects or doubtable behaviour of "standard" functions will be complicated and won't pay.

- To word it explicitly:

There isn't something like an "exact calculation" in the case.

- - There must be an

unmistakable specification for every case to be able to tell if a result is correct/exact.

- - Putting the results of a certain way of calculation into the role of a specification is evil.

MrProgrammer wrote: Lupp wrote: =(EndDate - StartDate) / 30.42

As you would know, this is an estimate which may be particularly vulnerable...

I don't understand the word "vulnerable" in the context. The reason should be explained sufficiently above.

In the other respect: I know, of course. Moreover this is intended. An estimate

not fogging its nature may be better, imo, than a result pretending to be "exact" where the term exact is doutable itself due to the context.

Eventually the user needs to decide if the information he(f/m) got is sufficient or if he needs to look at

Start and

End in the specific case. An automated further evaluation of the result should actually be considered vulnerable.

In short: We shouldn't try to use calendaric terms like "year", "month", "day" as if they are units of time.

Where traditional ways (in calculation of interest e.g.) is defined with respect to the numbers of years, months, days, we need three numeric results which can easily be referred to by formulas.