tdf#69569 ODFFv1.2 part 2 incorrect

[Eike Rathke]

Hi Winfried,

On Wednesday, 2018-11-14 10:37:33 +0000, Winfried Donkers wrote:

> I have been studying ODFFv1.2 part 2 §4.11.7.7 with https://bugs.documentfoundation.org/show_bug.cgi?id=69569#c17 , lines 1..5. in mind.

Many thanks for that! YEARFRAC() and its Basis algorithm also used in
other functions is an annoyance that hopefully will end now soon..

> My conclusions are that
> a) Line 8 should be
>     " 8.Otherwise, if _(not A)_ and is-leap-year(year(date1)) then return 366 ";

So, that with
Evaluate A: year(date1) != year(date2)
the if (not A) boils down to
if (year(date1) == year(date2)) and is-leap-year(year(date1)) then return 366

Makes sense.

> b) Lines 9 and 10 can be combined by appending inclusive to both dates, the current line 9 is ambiguous and line 10 does not fully solve that;

Sounds sensible.

> c) The constraint date1 >= date2 is missing in §4.11.7.

It's date1 <= date2, isn't it? As stated for the other procedures as
"If date1> date2, then swap the values of date1 and date2."
I think that's missing for procedure E.

> I have made logical diagrams to cheack that all possible combinations of date1 and date2 are covered - on the presumption that date1 >= date2.

That date1 >= date2 confuses me, date1 <= date2?

However, at https://dwheeler.com/yearfrac/ there still is
a calc_yearfrac.py available. It *seems* to me that it already
implements the correct algorithm with

    if (date1.year == date2.year and is_leap_year(date1.year)):
        year_length = 366.

in the basis1() function, but I didn't investigate deeper detail. Also,
it swaps date,date2 to get date1 <= date2 ...

There's also a huge set of data available, yearfrac_data_basis_all.zip
generated by Excel. It is said it was used to create the Python script.
If the script already implements the correct algorithm there's probably
nothing to do, but if not and needs modification, could you please
verify the change with that data? Might be easiest to try with that
before setting up Calc for it. Also two .ods files with some edge cases
are there.


> If you agree with my conclusions, would it be possible that you submit a proposal for changing ODFF to reflect the above? 
> I think that a proposal from you is more effective than one from me ;-)

Lol, I can do.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20181130/58ddc8fa/attachment.sig>