incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Date Sat, 03 Mar 2012 18:25:53 GMT
On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni <pfg@apache.org> wrote:
> On 03/03/12 10:12, Rob Weir wrote:
>>
>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<pfg@apache.org>  wrote:
>>>
>>> Hello;
>>>
>>> --- Sab 3/3/12, Andrea Pescetti<pescetti@apache.org>  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.

>
>> 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.

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.

> 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.
>

Mime
View raw message