You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2012/03/03 12:34:43 UTC
Nominate release blocker: 118999 - Leap year not correctly calculated
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.
Regards,
Andrea.
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/03/2012 12:34 PM, schrieb Andrea Pescetti:
> 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.
If it's without risk then integrate it but as releae blocker, hm, no.
Marcus
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Pedro Giffuni <pf...@apache.org>.
On 03/03/12 13:25, Rob Weir wrote:
> On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni<pf...@apache.org> wrote:
>> On 03/03/12 10:12, Rob Weir wrote:
>>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<pf...@apache.org> wrote:
>>>> Hello;
>>>>
>>>> --- Sab 3/3/12, Andrea Pescetti<pe...@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.
>>
RE: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by "Dennis E. Hamilton" <de...@acm.org>.
No, this is definitely not the Excel leap-year bug.
Compensation for the [Visicalc?]/Lotus/Excel Leap-Year bug is what has the default OO.o Calc serial-day for 1899-12-30 be 0 rather than have 1899-12-31 be serial-day 0 as it is in Excel. This way, all dates starting with March 1, 1900 have the same serial-day number as calendars with the leap-year bug.]
The leap-year bug is one that has 1900-02-29 be a valid leap day. You can see that OO.o Calc does not do that in the smoke test document I uploaded and in the screen captures.
For the serial days from 0 to 60, the dates will not line up and there will be other amazing differences (such as deviations in days of the week, the number of days between two dates that span across March 1, 1900, etc.).
Excel with the bug (the default, I believe) has serial days 0 to 60 line up with 1899-12-31 to 1900-02-29. OpenOffice.org lines them up with 1899-12-30 to 1900-02-28.
- Dennis
-----Original Message-----
From: Armin [mailto:Armin.Le.Grand@me.com]
Sent: Saturday, March 03, 2012 17:24
To: ooo-dev@incubator.apache.org
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Just wanted to add that I remember discussions on leap year handling (esp.
29th Feb 2000) together with a bug in MSOffice calc. There it was wrong and
correct in calc, the result was that it was changed in OOo calc (at SUN
times AFAIR) to be compatible with the behaviour of the 'de-facto
standard'. I just hope this is not the task we discuss about, there is no
good solution :-( Just my 2cents...
--
ALG
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Armin <Ar...@me.com>.
Just wanted to add that I remember discussions on leap year handling (esp.
29th Feb 2000) together with a bug in MSOffice calc. There it was wrong and
correct in calc, the result was that it was changed in OOo calc (at SUN
times AFAIR) to be compatible with the behaviour of the 'de-facto
standard'. I just hope this is not the task we discuss about, there is no
good solution :-( Just my 2cents...
--
ALG
RE: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by "Dennis E. Hamilton" <de...@acm.org>.
We've wandered away from the failure to convert 2000-02-29 and 2400-02-29 correctly on reading of those dates in saved Calc cells to a possible interaction with the Excel leap-year calendar bug. The Smoke test will also demonstrate whether or not that bug is evident in the Calc cases. It is not.
But the but should be revealed when transferring spreadsheets between Calc and Excel.
- Dennis
LOOKING AROUND FURTHER
[It would be good to build dataflow diagrams that explain these passing of documents through different consumers and producers. What follow below is not so meticulous. It is a trial. In order to work through this more systematically, there need to be more carefully staged tests and alternative smoke tests.]
In converting to Excel 2003 XML format, the result should be opened in Excel to see how much is preserved or not. The discrepancy for dates before 1900-03-01 should also appear.
If the serial days column data is lost, that is a bug in the export (or the re-import).
SAVING TO XLS (EXCEL 27/2000/ME)
I saved the Smoke Test document to Excel 97/2000/ME .xls format.
It round trips back into AOO just fine. All formatting is preserved.
If I open the saved .xls in Excel, it will show the dates from serial days 0 to 2 as 1900-01-00 (!), 1900-01-01, and 1900-01-02.
(It is not possible to enter 1900-01-00 as a date. Excel displays this because the 0 serial-day value was delivered in the cell exported by Calc. It is not possible to enter that date into the cell, though one can enter 0 into a numeric cell and then change its format to date, or obtain the 0 as a formula result, etc.)
Excel also shows Serial Day 60 as 1900-02-29. For all later dates and serial-day numbers, Calc and Excel agree completely, and the Calc formatting is preserved in Excel also. I added that screen shot to show how the Excel "leap-year bug" shows up using the same smoke test document.
LO 3.5.0 will open the .XLS file correctly as stored. (I see I have an error in the Smoke Test .ODP for the expected result in C16. It should be 2100-02-29, the value actually taken as text and not a date.)
SAVING TO XML (EXCEL 2003 XML FORMAT)
To save the Smoke Test as Excel 2003 XML format requires a JRE so it doesn't work on my bare Windows 8 64-bit and Vista SP1 32-bit test installs. To get quick results, I did the Excel 2003 XML format using the Oracle OOo-dev 3.4.0 that I have installed.
On round trip of the Excel XML format, by the time it gets back into Calc, the date formatting is changed (1899-12-30 becomes 30-12-99 on my configuration) and the serial days formulas are some mangled versions of the OpenFormula formulas that were in the original .odp. These are all Calc defects somewhere in the export to import path.
IMPORTANT: The roundtrip of this export DOES NOT demonstrate any 2000-02-29 or 2400-02-29 problem in OpenOffice or in Excel. Also, attempting to import this file into LO 3.5.0 fails with a General input/output error, perhaps because there is no JRE available. It opens in LO 3.3.2 with the same peculiar loss of formatting and column B formula mangling as in OOo-dev 3.4.
When I correct the formula in B3 in OpenOffice Calc and do a fill down to populate the rest in OO.o Calc, the correct values are revealed.
When I open the Excel XML version in Excel, there are a number of very strange things. I see the same date formatting as in the Smoke Test .ODP, but that is my default date format on the machine I ran Excel on, so it might be a coincidence. It appears that the export from Calc adjusts the date cell values with serial day value below 61 by subtracting 1, so the cell for 1889-12-30 comes into Excel with serial day number -1. The cells that OO.o did not accept leap day dates for came over as text (appropriately). On re-entering 1900-02-29 manually in cell A7, the serial day 60 shows up.
In column B, the formulas were not accepted by Excel. Instead, Excel simply presented the values that were in the XML file as the last-calculated values and dropped the formulas. This is probably an OO.o export bug that is not converting OpenFormula to Excel correctly. It could be that the XML export had not been updated properly when OpenOffice.org converted to OpenFormula (assuming that it once worked). If I manually correct column be by making cell B3 hold "=A3", fill down, and also change the column format to numbers with commas, you can see how dates from 1900-03-01 onward are in agreement with OpenOffice but the earlier dates don't work, and the correction by -1 for earlier dates actually creates an Excel error for 1899-12-30.
I made a screen capture of the cleaned-up Excel view also.
-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org]
Sent: Saturday, March 03, 2012 17:25
To: ooo-dev@incubator.apache.org
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated
On 03/03/12 17:34, Dennis E. Hamilton wrote:
> Amen on understanding the scope of the bug!!
>
> As promised, I built a smoke-test document and ran it. The bug does not appear at all in any Windows version of OpenOffice.org that I tested. In particular, it does not appear in OpenOffice.org 3.3.0, in the Oracle OOo-dev 3.4.0 developer release, nor in the Apache OpenOffice OOo-dev 3.4 Developer Snapshot r1293550.
>
> For more grounding, I confirmed that the bug also is missing from LibreOffice 3.3.2, the one I use for production, but it does appear in LibreOffice 3.5.0.
>
> So, whatever the origin of the defect, it apparently does not exist in the Apache OpenOffice lineage from OpenOffice.org.
>
> On the other hand, it would be good to keep the smoketest document around, just in case.
>
> The file and screen captures demonstrating the presence and absence of smoke are all attacked to the AOO Bugzilla report #118999.
>
The code is only used for conversions and apparently recent
versions of LO use it more aggressively but I can't find huge
differences with what we do (not that I looked too hard).
In any case I did a conversion of Dennis' file to Excel XML and
while the result is ugly (the "Serial days" information is lost and
1899 is formatted "99"), the dates are still consistent.
I am doing more tests converting stuff but for now I changed
the status to "irreproducible". As originally planned I wont
commit my patch for 3.4 but it still looks like a latent bug
waiting to strike so I will test Dennis' file with my patch for
inclusion after the release.
Thank you, Dennis!
cheers,
Pedro.
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Pedro Giffuni <pf...@apache.org>.
On 03/03/12 17:34, Dennis E. Hamilton wrote:
> Amen on understanding the scope of the bug!!
>
> As promised, I built a smoke-test document and ran it. The bug does not appear at all in any Windows version of OpenOffice.org that I tested. In particular, it does not appear in OpenOffice.org 3.3.0, in the Oracle OOo-dev 3.4.0 developer release, nor in the Apache OpenOffice OOo-dev 3.4 Developer Snapshot r1293550.
>
> For more grounding, I confirmed that the bug also is missing from LibreOffice 3.3.2, the one I use for production, but it does appear in LibreOffice 3.5.0.
>
> So, whatever the origin of the defect, it apparently does not exist in the Apache OpenOffice lineage from OpenOffice.org.
>
> On the other hand, it would be good to keep the smoketest document around, just in case.
>
> The file and screen captures demonstrating the presence and absence of smoke are all attacked to the AOO Bugzilla report #118999.
>
The code is only used for conversions and apparently recent
versions of LO use it more aggressively but I can't find huge
differences with what we do (not that I looked too hard).
In any case I did a conversion of Dennis' file to Excel XML and
while the result is ugly (the "Serial days" information is lost and
1899 is formatted "99"), the dates are still consistent.
I am doing more tests converting stuff but for now I changed
the status to "irreproducible". As originally planned I wont
commit my patch for 3.4 but it still looks like a latent bug
waiting to strike so I will test Dennis' file with my patch for
inclusion after the release.
Thank you, Dennis!
cheers,
Pedro.
RE: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Amen on understanding the scope of the bug!!
As promised, I built a smoke-test document and ran it. The bug does not appear at all in any Windows version of OpenOffice.org that I tested. In particular, it does not appear in OpenOffice.org 3.3.0, in the Oracle OOo-dev 3.4.0 developer release, nor in the Apache OpenOffice OOo-dev 3.4 Developer Snapshot r1293550.
For more grounding, I confirmed that the bug also is missing from LibreOffice 3.3.2, the one I use for production, but it does appear in LibreOffice 3.5.0.
So, whatever the origin of the defect, it apparently does not exist in the Apache OpenOffice lineage from OpenOffice.org.
On the other hand, it would be good to keep the smoketest document around, just in case.
The file and screen captures demonstrating the presence and absence of smoke are all attacked to the AOO Bugzilla report #118999.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Saturday, March 03, 2012 14:12
To: ooo-dev@incubator.apache.org
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated
On Sat, Mar 3, 2012 at 2:38 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> 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 was hoping that OO did not have several independent places where
leap year logic was coded, some with bugs, some without. But if it
the case that this bug is only in the data input and conversion logic
and not in the calculation logic, then great. But I think that would
need to come from analysis of the code dependencies, not analysis of
the defect report.
Hopefully we agree that understanding the scope of the bug is a real
good thing here,
-Rob
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 3, 2012 at 2:38 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> 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 was hoping that OO did not have several independent places where
leap year logic was coded, some with bugs, some without. But if it
the case that this bug is only in the data input and conversion logic
and not in the calculation logic, then great. But I think that would
need to come from analysis of the code dependencies, not analysis of
the defect report.
Hopefully we agree that understanding the scope of the bug is a real
good thing here,
-Rob
RE: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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 [mailto:robweir@apache.org]
Sent: Saturday, March 03, 2012 10:26
To: ooo-dev@incubator.apache.org
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated
On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
> On 03/03/12 10:12, Rob Weir wrote:
>>
>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<pf...@apache.org> wrote:
>>>
>>> Hello;
>>>
>>> --- Sab 3/3/12, Andrea Pescetti<pe...@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.
>
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 3, 2012 at 12:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
> On 03/03/12 10:12, Rob Weir wrote:
>>
>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<pf...@apache.org> wrote:
>>>
>>> Hello;
>>>
>>> --- Sab 3/3/12, Andrea Pescetti<pe...@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.
>
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Pedro Giffuni <pf...@apache.org>.
On 03/03/12 10:12, Rob Weir wrote:
> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni<pf...@apache.org> wrote:
>> Hello;
>>
>> --- Sab 3/3/12, Andrea Pescetti<pe...@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.
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Pedro Giffuni <pf...@apache.org>.
On 03/03/12 16:26, Andrea Pescetti wrote:
> Rob Weir wrote:
>> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni wrote:
>>> --- Sab 3/3/12, Andrea Pescetti ha scritto:
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=118999
>>>> The fix should definitely be integrated in 3.4.
>
> We already have more messages in this discussion than characters in
> the patch, anyway... By "nominating as blocker" I simply meant that
> the fix should be checked in before 3.4; seeing that Pedro had the fix
> ready but had not committed it, I merely wanted to ask to include it.
> (By the way, regressions should qualify as blockers, but I accept
> Marcus' view that this is not a huge bug, while annoying).
>
>>> 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.
>
> No, that bug is closed invalid and has nothing to do with leap years.
> This is a new bug, introduced by CWS sw33bf02,
FWIW, I don't think the original issue was actually invalid: the lack
of support for leap years was likely to be the cause behind the
code in that CWS. It's all pretty irrelevant history at this
time though: the code is broken and there is a fix for testing.
I agree this thread is already too long for something so simple.
cheers,
Pedro.
> and you can read the description from the developer's words in
> http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg24634.html
>
> and in the same thread you can see the LibreOffice fix that is
> equivalent to the one by Pedro:
> http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg24587.html
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=a2d96b51f3272ecbdc0f4f9d4b2ee65409892554
>
>
>> 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
>
> Given the discussion above, I'd be confident that the fix can be
> committed. This is not a decade-old bug hidden in an obscure part of
> the source code, a situation where I would have the same perplexity
> you express.
>
>> I'd be far more confident if we had a test document that did a
>> comprehensive test of date calculations, including leap year
>> calculations.
>
> You can find reasonable suggestions (unit tests) in the discussion
> above, but indeed test documents would be nice to start with.
>
> Regards,
> Andrea.
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni wrote:
>> --- Sab 3/3/12, Andrea Pescetti ha scritto:
>>> https://issues.apache.org/ooo/show_bug.cgi?id=118999
>>> The fix should definitely be integrated in 3.4.
We already have more messages in this discussion than characters in the
patch, anyway... By "nominating as blocker" I simply meant that the fix
should be checked in before 3.4; seeing that Pedro had the fix ready but
had not committed it, I merely wanted to ask to include it. (By the way,
regressions should qualify as blockers, but I accept Marcus' view that
this is not a huge bug, while annoying).
>> 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.
No, that bug is closed invalid and has nothing to do with leap years.
This is a new bug, introduced by CWS sw33bf02, and you can read the
description from the developer's words in
http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg24634.html
and in the same thread you can see the LibreOffice fix that is
equivalent to the one by Pedro:
http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg24587.html
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=a2d96b51f3272ecbdc0f4f9d4b2ee65409892554
> 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
Given the discussion above, I'd be confident that the fix can be
committed. This is not a decade-old bug hidden in an obscure part of the
source code, a situation where I would have the same perplexity you express.
> I'd be far more confident if we had a test document that did a
> comprehensive test of date calculations, including leap year
> calculations.
You can find reasonable suggestions (unit tests) in the discussion
above, but indeed test documents would be nice to start with.
Regards,
Andrea.
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 3, 2012 at 9:21 AM, Pedro Giffuni <pf...@apache.org> wrote:
> Hello;
>
> --- Sab 3/3/12, Andrea Pescetti <pe...@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'd be far more confident if we had a test document that did a
comprehensive test of date calculations, including leap year
calculations.
> Thanks for looking at the bug and patch!
>
> Pedro.
>
Re: Nominate release blocker: 118999 - Leap year not correctly calculated
Posted by Pedro Giffuni <pf...@apache.org>.
Hello;
--- Sab 3/3/12, Andrea Pescetti <pe...@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.
Thanks for looking at the bug and patch!
Pedro.