[Bug classpath/22957] java.util.Calendar broken with certain operations

[gcc-bugzilla at gcc dot gnu dot org]

The following sequence of statements illustrates a bug in Calendar:

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss:SSS");
Calendar cal = Calendar.getInstance();
cal.set(2005, 4, 25, 20, 50, 30);
cal.set(Calendar.MILLISECOND, 333);
Date date = cal.getTime();
Calendar ccal = Calendar.getInstance();
ccal.setTime(new Date(date.getTime()));
System.out.println(df.format(ccal.getTime()));
ccal.set(Calendar.MONTH, 0);
System.out.println(df.format(ccal.getTime()));

The output is:

2005-05-25 20:50:30:333
1970-01-01 00:00:00:000

But should be:

2005-05-25 20:50:30:333
2005-01-25 20:50:30:333

Many variations of the above work.  I encountered this from a failing Lucene
JUnit test.  Other that this, Lucene works with GNU Classpath.  However, the
above breaks Lucene's DateTools, which are routinely used for time-tagging
indexed documents.


------- Comment #1 from from-classpath at savannah dot gnu dot org  2005-06-01 
09:14 -------
Interesting.. Because the following DOES work:

    cal.set(2005, 4, 25, 20, 50, 30);
    cal.set(Calendar.MILLISECOND, 333);
    System.out.println(cal.getTime());
    cal.set(Calendar.MONTH, 0);
    System.out.println(cal.getTime());

How strange. I'll see why this is. :)


------- Comment #2 from from-classpath at savannah dot gnu dot org  2005-06-01 
15:21 -------
Thanks for the report, I just commited the fix to CVS.

The setTime() method wasn't recalculating the fields, which it should do,
although the set() method does not. 

So while getTime() will return the correct results after a getTime(), setting a
single field will be wrong since the rest of them haven't been updated.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22957