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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
