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
Attachment:
signature.asc
Description: PGP signature