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 22:34:52 GMT
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 that I tested.  In particular, it does not appear in 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

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 [] 
Sent: Saturday, March 03, 2012 14:12
Subject: Re: Nominate release blocker: 118999 - Leap year not correctly calculated

On Sat, Mar 3, 2012 at 2:38 PM, Dennis E. Hamilton
<> 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,


View raw message