On 03/03/12 13:25, Rob Weir wrote:
On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni<[email protected]> wrote:
On 03/03/12 10:12, Rob Weir wrote:
On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<[email protected]> wrote:
Hello;
--- Sab 3/3/12, Andrea Pescetti<[email protected]> ha scritto:
Issue 118999 is about a bug in an
integrated CWS, that fails to understand 29/2/2000
correctly:
https://issues.apache.org/ooo/show_bug.cgi?id=118999
It is a regression with respect to OOo 3.3.0 and has a
trivial fix, posted by Pedro (thanks!).
The fix should definitely be integrated in 3.4.
Looking at this issue:
https://issues.apache.org/ooo/show_bug.cgi?id=25987
I got to the conclusion that this is a long standing
bug that has been mutating for some time.
I think that the fix is safe and I would have just
gone ahead and committed it if we weren't so near a
release. Of course I have been breaking the build
more than once lately so I am sure some self-discipline
from my side during these days is appreciated ;-).
In any case, I don't think this is technically a
release blocker but I think we could just apply it.
Are we sue that fixing this bug doesn't bring in another bug? I'd
worry that there is other code compensating for this bug and that
fixing in one place introduces a new bug. Are we wiling to retest
all date-related calculations, including financial functions, date
arithmetic, etc.,
I think you are lacking an understanding of the issue.
We are replacing a wrong formula with a correct one and by
sheer "luck" the previous formula only produced bad results
for 1 day every 400 years. I don't think any financial function,
etc, depends on the leap year calculation but even then
I doubt it has the consecuences you are trying to imply.
I am not lacking understanding of this issue, Pedro. I wrote the
portion of the ODF 1.2 standard that deals with the interaction of
leap year calculations and spreadsheet financial calculations. It is
not just an issue of calculations done on "1 day every 400 years".
There are issues with date ranges that include such dates as well.
With mortages of of 30 years, bonds of 40 or more years, etc., we
cannot so easily dismiss this issue as trivial. There are many
current financial calculations that will have date ranges that include
February 2000.
Most rates are given are either monthly or yearly basis so leap year
adjustments are not made (at least not in the formulas I learned
from school). and in the rare case that you need a day by day
discrimination, the result will be extremely difficult to verify:
assuming you generated your data with Excel you have 1 date
out of range but still you have the correct value in your operations
because you still have the correct number of days.
What I mean here is that it may have some remote implications but
it would really surprise me if such error was ever adjusted for.
I'd be far more confident if we had a test document that did a
comprehensive test of date calculations, including leap year
calculations.
I personally think that's a waste of time just for this function,
but yes, in general it would be nice to have a regression test
suite for all these functions.
I've given several presentations on this topic. I'll ask you to consider this:
What do you call an economist whose calculations are wrong by 10%?
Answer: A genius.
What do you call an accountant whose calculations are wrong by $10?
Answer: A thief.
Indeed I think I've heard that joke before among accountants.
I have a huge respect for the, usually undervalued, work
accountants do and while they generally use specialized software
for their work, this bug is a good reason to advise them to avoid
OpenOffice.
This is not a waste of time. Although the error may be only 1 in 400,
from the user's perspective any error at all in financial calculations
is intolerable. It comes down to trust in the calculations.
I am not saying it's a complete waste of time, but it is a waste of
*my* time so under all circumstances feel free to do it. I am not
under any hurry to commit the patch, this can wait for 4.0 but
there *is* a bug.
Pedro.
Such tests are much more useful when someone unbiased,
(like someone different from the one that fixed it) does it.
So please just go ahead: the BZ report includes an important
date for your tests.
Pedro.
