Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F52529D.80701@apache.org>
Date: Sat, 03 Mar 2012 12:19:25 -0500
From: Pedro Giffuni <pfg@apache.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly
 calculated
References: <4F5201D3.9060905@apache.org>
 <1330784491.35146.YahooMailClassic@web113520.mail.gq1.yahoo.com>
 <CAP-ksohZnLNM-QyLcsNJ2KBZ+aJWwxYh6+7iHqOUeydPirvEsg@mail.gmail.com>
In-Reply-To: 
 <CAP-ksohZnLNM-QyLcsNJ2KBZ+aJWwxYh6+7iHqOUeydPirvEsg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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.