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:[email protected]] Sent: Saturday, March 03, 2012 17:24 To: [email protected] 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
