-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
6u10
-
x86
-
linux
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux dels-laptop 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Eclipse (Europa) IDE, but behaviour is the same from command line
A DESCRIPTION OF THE PROBLEM :
Using a Calendar object, as recommended, to subtract two dates (1-Jan-2000 and 1-Feb-2000) gives a difference of 29 days.
In fact, the dates from GetTime() are 1-Feb-2000 and 1-Mar-2000, respectively.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A test program is included below.
Logically the program
a) creates a Calendar instance and sets the date to 2000,1,1
b) saves the result of GetTimeInMillis()
c) sets the date to 2000,2,1
d) saves the result of GetTimeInMillis()
e) subtracts the first from the second and divides by 86,400,000 to convert to days
f) prints the difference in days
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In this case the difference should be 31.
ACTUAL -
The output is
------------------
Days between 1-Jan-2000 and 1-Feb-2000 (should be 31) = 29
------------------
NOTE: if you uncomment the "Date" statements, you see that "Calendar.GetTime()" does not return the time specified in Calendar.set() but return the first date of the next month.
This is a serious bug if used for commercial applications!
I want to use it for astronomy and it produces garbage.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/* ---------------------------------------------------------- */
package TestCalendar;
import java.util.TimeZone;
/**
* Testing the Calendar class in java.util
**/
class TestCalendar
{
public static void main( String[] arguments ) {
TimeZone tz = TimeZone.getTimeZone("UK/Greenwich");
Calendar testCal = Calendar.getInstance(tz);
// First create a Calendar object at 1-Jan-2000
testCal.set(2000, 1, 1, 0, 0);
long ms1 = testCal.getTimeInMillis();
// Date d1 = testCal.getTime();
// Then create a Calendar object at 1-Feb-2000
testCal.set(2000, 2, 1, 0, 0);
long ms2 = testCal.getTimeInMillis();
// Date d2 = testCal.getTime();
// DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL,DateFormat.LONG,Locale.UK);
// System.out.println("d1="+df.format(d1));
// System.out.println("d2="+df.format(d2);
System.out.println("Days between 1-Jan-2000 and 1-Feb-2000 (should be 31) = "+(ms2-ms1)/86400000);
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Reinstate the Deprecated methods in the Date class!
This class is a waste of resources for those who want to manipulate dates.
Temporarily, I will create my own Julian Date class based on the "rata die" calculation I have used since the 1970's
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux dels-laptop 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Eclipse (Europa) IDE, but behaviour is the same from command line
A DESCRIPTION OF THE PROBLEM :
Using a Calendar object, as recommended, to subtract two dates (1-Jan-2000 and 1-Feb-2000) gives a difference of 29 days.
In fact, the dates from GetTime() are 1-Feb-2000 and 1-Mar-2000, respectively.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A test program is included below.
Logically the program
a) creates a Calendar instance and sets the date to 2000,1,1
b) saves the result of GetTimeInMillis()
c) sets the date to 2000,2,1
d) saves the result of GetTimeInMillis()
e) subtracts the first from the second and divides by 86,400,000 to convert to days
f) prints the difference in days
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In this case the difference should be 31.
ACTUAL -
The output is
------------------
Days between 1-Jan-2000 and 1-Feb-2000 (should be 31) = 29
------------------
NOTE: if you uncomment the "Date" statements, you see that "Calendar.GetTime()" does not return the time specified in Calendar.set() but return the first date of the next month.
This is a serious bug if used for commercial applications!
I want to use it for astronomy and it produces garbage.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/* ---------------------------------------------------------- */
package TestCalendar;
import java.util.TimeZone;
/**
* Testing the Calendar class in java.util
**/
class TestCalendar
{
public static void main( String[] arguments ) {
TimeZone tz = TimeZone.getTimeZone("UK/Greenwich");
Calendar testCal = Calendar.getInstance(tz);
// First create a Calendar object at 1-Jan-2000
testCal.set(2000, 1, 1, 0, 0);
long ms1 = testCal.getTimeInMillis();
// Date d1 = testCal.getTime();
// Then create a Calendar object at 1-Feb-2000
testCal.set(2000, 2, 1, 0, 0);
long ms2 = testCal.getTimeInMillis();
// Date d2 = testCal.getTime();
// DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL,DateFormat.LONG,Locale.UK);
// System.out.println("d1="+df.format(d1));
// System.out.println("d2="+df.format(d2);
System.out.println("Days between 1-Jan-2000 and 1-Feb-2000 (should be 31) = "+(ms2-ms1)/86400000);
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Reinstate the Deprecated methods in the Date class!
This class is a waste of resources for those who want to manipulate dates.
Temporarily, I will create my own Julian Date class based on the "rata die" calculation I have used since the 1970's