Hi there,
The attached patch fixes a bug in our current leap year calculation
code. It is based on the algorithm posted on wikipedia[1], and seems to
correctly identify year 2000 as a leap year.
Without this, Calc would convert 2000-2-29 into 1899-12-30 on load,
which is ugly but very hard to detect.
Please consider this for 3.5.1, in which case I'll need 3 sign-offs. I
haven't pushed this to master yet. I wanted to run it by Eike first
before pushing to master.
Kohei
[1] http://en.wikipedia.org/wiki/Leap_year
--
Kohei Yoshida, LibreOffice hacker, Calc
>From 0666b5dca1a210ce7abc61a522a59c48661fe664 Mon Sep 17 00:00:00 2001
From: Kohei Yoshida <kohei.yosh...@suse.com>
Date: Tue, 28 Feb 2012 22:01:52 -0500
Subject: [PATCH] Correctly calculate leap year.
With the old code, year 2000 would not be a leap year, but it actually
is. With this, Calc correctly loads cell with date value of 2000-2-29.
---
sax/source/tools/converter.cxx | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sax/source/tools/converter.cxx b/sax/source/tools/converter.cxx
index eb8cc74..95f6494 100644
--- a/sax/source/tools/converter.cxx
+++ b/sax/source/tools/converter.cxx
@@ -1304,7 +1304,7 @@ readDateTimeComponent(const ::rtl::OUString & rString,
static bool lcl_isLeapYear(const sal_uInt32 nYear)
{
return ((nYear % 4) == 0)
- && !(((nYear % 100) == 0) || ((nYear % 400) == 0));
+ && (((nYear % 100) != 0) || ((nYear % 400) == 0));
}
static sal_uInt16
--
1.7.3.4
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
