Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <24200376.500411279736093042.JavaMail.jira@thor>
Date: Wed, 21 Jul 2010 14:14:53 -0400 (EDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4752) CheapDateFormatter returns incorrect
 and invalid date strings
In-Reply-To: <6650973.494891279712629887.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890803#action_12890803 ] 

Knut Anders Hatlen commented on DERBY-4752:
-------------------------------------------

Instead of trying to fix the algorithm, I think it would be better to rely on java.util.Calendar to do these calculations for us. That would require allocating a Calendar object each time the method is called (in addition to all the String objects the method already allocates), but it won't instantiate any ResourceBundles or Locales, which was the reason why CheapDateFormatter was written in the first place, according to the comments. I haven't found that CheapDateFormatter is used in any performance critical section of the code, so I'm not sure if that's much of a concern in any case.

> CheapDateFormatter returns incorrect and invalid date strings
> -------------------------------------------------------------
>
>                 Key: DERBY-4752
>                 URL: https://issues.apache.org/jira/browse/DERBY-4752
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.7.0.0
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>
> CheapDateFormatter has multiple problems. These are the ones I'm aware of:
> 1) On the boundary between non-leap years and leap years it will return first day of thirteenth month in previous year (for instance, 2011-13-01 instead of 2012-01-01)
> 2) It treats all years divisible by four as leap years. Those divisible by 100 and not by 400 are not leap years. It attempts to adjust for that (see the snippet below) but it always ends up setting leapYear=true if (year%4)==0.
> 		// It's a leap year if divisible by 4, unless divisible by 100,
> 		// unless divisible by 400.
> 		if ((year % 4L) == 0) {
> 			if ((year % 100L) == 0) {
> 				if ((year % 400L) == 0) {
> 					leapYear = true;
> 				}
> 			}
> 			leapYear = true;
> 		}
> 3) More leap year trouble. To find out which year it is, it calculates the number of four year periods that have elapsed since 1970-01-01. A four year period is considered 365*3+366 days. Although most four year periods are of that length, some are shorter, so we'll get one day off starting from year 2100, two days off from year 2200, and so on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.