incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Nominate release blocker: 118999 - Leap year not correctly calculated
Date Sat, 03 Mar 2012 19:38:10 GMT
The reported bug is about a date conversion error on loading of a stored ODP file.  It appears
from the description that the conversion fails and a serial-date number of 0 results.  

If it can be confirmed that the error is localized to that case, the fix has to be benign.
 This would be unrelated to whether or not there are other defects involving serial-date numbers
that correspond to the leap days on any calendar.  

I assume if the bug description is to be believed, and the defect is allowed to remain, it
will effectively alter existing correct ODP files that have such dates when loaded in AOO
3.4.  That does not strike me as an useful thing to countenance, especially if the effect
is also to incorrectly consume documents from other producers.  It looks like a small item
to add to the list of changes in AOO 3.4.  (By the way, it is plausible any spreadsheet-level
workaround would likely simply not be triggered when the defect does not show up any longer.)

It should be possible to confirm that such dates can be entered into cells with impunity,
that they are presented correctly in whatever the chosen format is, that they are stored with
the correct ISO 8601 date and/or the correct serial-date value and the export is correct.
 These are functions that should already be working.  

I agree that this means someone needs to produce a Calc spreadsheet that exercises enough
to see that no edge case is triggered in the presented document, in the stored ODP, and in
reloading the ODP (which should exhibit the bug in a current developer snapshot).   I will
do that and attach the result to the bug.  It's more fun than arguing about whether fixing
the on-load defect will have unintended consequences. 

 - Dennis

-----Original Message-----
From: Rob Weir [] 
Sent: Saturday, March 03, 2012 10:26
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated

On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni <> wrote:
> On 03/03/12 10:12, Rob Weir wrote:
>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<>  wrote:
>>> Hello;
>>> --- Sab 3/3/12, Andrea Pescetti<>  ha scritto:
>>>> Issue 118999 is about a bug in an
>>>> integrated CWS, that fails to understand 29/2/2000
>>>> correctly:
>>>> 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:
>>> 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.

View raw message