[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.util.Date mess

From: Bryce McKinlay
Subject: Re: java.util.Date mess
Date: Tue, 12 Oct 2004 20:11:03 -0400
User-agent: Mozilla Thunderbird 0.8 (X11/20040913)

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,

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]