-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.3.1_13
-
other
-
solaris_9
OPERATING SYSTEM(S)
Solaris
FULL JDK VERSION(S):
1.3.1_13
DESCRIPTION:
Under the EST5EDT timezone, the 1.3.1 JDK returns incorrect time information for certain dates in periods when DST is active. One example is 08/01/1998.
The problem does not occur with the 1.4.2 JDK.
A testcase is provided at the end of this report. It compares the returned time with the expected time for 08/01/1998 in terms of the number of milliseconds elapsed since 01/01/1970. It can be run as follows:
java DateTest 08/01/1998
Results for 1.3.1_13, with TZ=EST5EDT:
Date entered = 08/01/1998, SQL Time = 901947600000
Date entered = 08/01/1998, UTIL Time = 901947600000
Expected Time result for 08/01/1998 : 901944000000
Results for 1.4.2_07 under identical conditions:
Date entered = 08/01/1998, SQL Time = 901944000000
Date entered = 08/01/1998, UTIL Time = 901944000000
Expected Time result for 08/01/1998 : 901944000000
------ Start testcase DateTest.java ------
import java.util.*;
import java.text.*;
public class DateTest {
public static void main ( String [] args ) {
String enteredDate = args[0];
String format = "MM/dd/yyyy";
DateFormat df = new SimpleDateFormat(format);
java.util.Date d = null;
java.sql.Date date = null;
df.setLenient(false);
try {
d = df.parse(enteredDate);
}
catch (ParseException pe) {
throw new IllegalArgumentException(pe.getMessage());
}
date = new java.sql.Date(d.getTime());
long dateTime = date.getTime();
d = new java.util.Date(d.getTime());
System.out.println("Date entered = "+enteredDate+", SQL Time = \t\t"+date.getTime());
System.out.println("Date entered = "+enteredDate+", UTIL Time = \t\t"+d.getTime());
System.out.println("Expected Time result for 08/01/1998 : \t\t901944000000");
}
}
------ End testcase DateTest.java ------
###@###.### 2005-2-21 16:38:26 GMT
Solaris
FULL JDK VERSION(S):
1.3.1_13
DESCRIPTION:
Under the EST5EDT timezone, the 1.3.1 JDK returns incorrect time information for certain dates in periods when DST is active. One example is 08/01/1998.
The problem does not occur with the 1.4.2 JDK.
A testcase is provided at the end of this report. It compares the returned time with the expected time for 08/01/1998 in terms of the number of milliseconds elapsed since 01/01/1970. It can be run as follows:
java DateTest 08/01/1998
Results for 1.3.1_13, with TZ=EST5EDT:
Date entered = 08/01/1998, SQL Time = 901947600000
Date entered = 08/01/1998, UTIL Time = 901947600000
Expected Time result for 08/01/1998 : 901944000000
Results for 1.4.2_07 under identical conditions:
Date entered = 08/01/1998, SQL Time = 901944000000
Date entered = 08/01/1998, UTIL Time = 901944000000
Expected Time result for 08/01/1998 : 901944000000
------ Start testcase DateTest.java ------
import java.util.*;
import java.text.*;
public class DateTest {
public static void main ( String [] args ) {
String enteredDate = args[0];
String format = "MM/dd/yyyy";
DateFormat df = new SimpleDateFormat(format);
java.util.Date d = null;
java.sql.Date date = null;
df.setLenient(false);
try {
d = df.parse(enteredDate);
}
catch (ParseException pe) {
throw new IllegalArgumentException(pe.getMessage());
}
date = new java.sql.Date(d.getTime());
long dateTime = date.getTime();
d = new java.util.Date(d.getTime());
System.out.println("Date entered = "+enteredDate+", SQL Time = \t\t"+date.getTime());
System.out.println("Date entered = "+enteredDate+", UTIL Time = \t\t"+d.getTime());
System.out.println("Expected Time result for 08/01/1998 : \t\t901944000000");
}
}
------ End testcase DateTest.java ------
###@###.### 2005-2-21 16:38:26 GMT
- duplicates
-
JDK-5031170 1.3.1_11 only: GregorianCalendar uses wrong ERA value in non-lenient mode
- Resolved