Hi Winfried, On Tuesday, 2012-05-15 08:09:37 +0200, Winfried Donkers wrote:
You did a lot of work! I expected some or a lot of comments on my interpretations of ODF1.2 as i don't have Excel to compare with, but you did all the work yourself! I'm a volunteer, I don't mind cleaning up (my own) mess :)
Heh, sorry for having taken away the work from you :-) I'll keep that in mind for next time. I thought I'd get that algorithm solved because I quite know the date calculation area and the quirks that may be lurking there.
Some detailed nitpicks in commit comments :-)If I'm correct, the main changes are that my interpretation of ignore years/months were not right.
Hm, yes. I wouldn't say it's your fault though, the ODFF definition is a bit weak to implement that from scratch if one is not familiar with the area.
There is one thing I am not very happy about: DATEDIF in calc now does not accept date1 to be later (larger) than date2. IMHO this should be possible as it is a very normal possibilty. It looks as if DATEDIF does not accept this condition because Excel doesn't/can't. I thought calc conforms to ODF and can export to xls(x) but with possible loss of functionality. Now it is like LibreOffice is an open source copy of MS Office.
Usually for spreadsheet functions we strive for Excel interoperability. (Actually they implemented this function because Lotus 1-2-3 had it the same way, anyway...) If we allowed reversed date arguments, importing a document in Excel would give different results, errors in this case. The ODFF definition lacks a constraint that date1 must be <= date2, seems we didn't think of that back then, I'll submit a comment. Also Gnumeric implemented it the same.
I would very much like to adjust the code to make it possible again for date1 to be later (larger) than date2, both to increase its use :) and because I don't want to be a follower of MS Office :(
I'd rather stick with the current implementation for the above reasons.
And a big thank you for all your corrections/inprovements! I hope to be able to send in more formula based patches, I like this area:)
Great! I'm looking forward. Do you have already an idea what you'll pick next? Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Attachment:
pgpbUoHShQxlO.pgp
Description: PGP signature