This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Date/Calendar related fixes (?)


In order to get my app to work right I had to make a couple of patches. I'm not
sure
if they'll turn out to be correct.

First in natGregorianCalendar.cc, java::util::GregorianCalendar::computeTime,
line 60

> time = t * 1000LL + elements(fields)[MILLISECOND];

On my platform, i586-pc-linux-gnu/Debian an 32 bit overflow results. I basically
made
1000 a long long constant. There must be a better way eg. using a cast in a
platform
independant way, but I don't know my way around the code yet.

Second in Calendar.java, setTimeInMillis, line 249

> computeFields();

I replaced clear() with computeFields(). My app extensively uses
Date.setMinute() etc.
Reading the code its a 'chicken before the egg' situation regarding fields and
the
computed time. As the primary function of the calendar is to convert fields to a

millisecond time it would seem that the potential penalty of a computeFields
call in
setTimeInMillis is worth the extra logic that would be needed to detect a
computed
time before computed fields state.

A simple program that shows uninitialized fields causing a rogue date:

import java.util.Date;
public class Test {
  static public void main(String[] args)  {
    Date d=new Date();
    System.out.println(d);
    d.setMinutes(0);
    System.out.println(d);
  }
}

Hope that these two pointers result in official fixes. My app is running now :-)

Regards,

Mike Leddy.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]