Re: java.util.Date mess

[Bryce McKinlay]

Jeroen Frijters wrote:

> Hi,
>
> I have some code that depends on unspecified behavior of java.util.Date.
> In the Sun JDK if you pass out of range parameters to the Date
> constructors that take year, month, date, etc. it will automatically
> convert to a valid date (for example, new Date(104, 8, 41) is Oct 11,
> 2004.)
>
> I have a rather lame patch that addresses this (see below), would anyone
> object to this?
>  

Hi Jeroen,

Unfortunately I don't think this patch is the correct fix. 
GregorianCalendar should already "roll over" overflowed date values, 
regardless of whether these are set by the constructor or by the add() 
method - check the test case below for an example - so I believe the way 
the Date() constructors are calling GregorianCalendar are correct.

import java.util.*;

public class Cal6
{
 public static void main (String[] args)
 {
   Calendar cal = new GregorianCalendar(2004, 1, 45);
   System.out.println (cal.get(Calendar.DAY_OF_MONTH));
 }
}

I think the real problem lies in the interaction between 
GregorianCalendar and TimeZone - we need to make sure the DAY_OF_MONTH 
and other values in a lenient calendar instance get normalized before 
querying the TimeZone.

Interestingly, I did some tests with overriding 
SimpleTimeZone.getOffset() and it seems that Sun's implementation of 
GregorianCalendar never actually calls this method. Perhaps they have 
some private internal interface between Calendar and TimeZone.

Regards

Bryce