incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Date Sat, 03 Mar 2012 19:00:10 GMT
On 03/03/12 13:25, Rob Weir wrote:
> 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.

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


Mime
View raw message