Bryce McKinlay wrote: > Jeroen Frijters wrote: > >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? > > 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.
Ugh. Thanks. So this basically means that GregorianCalendar is totally broken, between this bug, the fact that it croaks on new GregorianCalendar(1970, 0, 1).get(Calendar.DAY_OF_MONTH) and the bug that Stephen Crawley posted about. > 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. Yes. I'll see if I can get it fixed. Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
