Details
Description
CheapDateFormatter has multiple problems. These are the ones I'm aware of:
1) On the boundary between nonleap years and leap years it will return first day of thirteenth month in previous year (for instance, 20111301 instead of 20120101)
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;
}
3) More leap year trouble. To find out which year it is, it calculates the number of four year periods that have elapsed since 19700101. 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.
Issue Links
 relates to

DERBY5391 The syscs_diag.error_log_reader() and syscs_diag.statement_duration() vtis do not work on derby error logs created since 10.7.1
 Closed
Activity
 All
 Comments
 Work Log
 History
 Activity
 Transitions
Examples:
Issue 1:
CheapDateFormatter.formatDate(1325376000000L) returns "20111301 00:00:00.000 GMT", expected: "20120101 00:00:00.000 GMT"
The returned date is wrong and invalid because there is no month 13.
Issue 2:
CheapDateFormatter.formatDate(4114195200000L) returns "21000516 00:00:00.000 GMT", expected: "21000517 00:00:00.000 GMT"
The returned date is one day off.
Issue 3:
CheapDateFormatter.formatDate(4107542400000L) returns "21000229 00:00:00.000 GMT", expected "21000301 00:00:00.000 GMT"
The returned date is invalid because there is no February 29 in the year 2100.