db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4752) CheapDateFormatter returns incorrect and invalid date strings
Date Thu, 22 Jul 2010 13:29:53 GMT

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

Kathey Marsden commented on DERBY-4752:
---------------------------------------

I am not really sure if this is at all relevant at this time, but this issue brought back
memories because it touched on my first ever technical conversation regarding what was at
that time Cloudscape with Jeff Lichtman.  I seem to recall he had implemented CheapDateFormatter
because it was found just printing the date to the log was taking huge amounts of time.  Of
course Calendar did not exist at that time, so I don't know if the performance is acceptable.
Also I think any performance impact was probably more closely related to being able to test
performance with statement logging, etc turned on than a typical user scenario, but I thought
I would mention this bit of history in case performance of the new CheapDateFormatter needs
to be measured.



> 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
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-4752-1a.diff, derby-4752-1b.diff, derby-4752-1c.diff
>
>
> 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.


Mime
View raw message