FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20060421 (SR5) (JIT enabled: jitc))
and
java version "1.4.2_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_14-b05)
Java HotSpot(TM) Client VM (build 1.4.2_14-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 2.4.21-20.EL #1 Wed Aug 18 20:58:25 EDT 2004 i686 i686 i386 GNU/Linux
Windows XP Professional Version 2002 Service Pack 2
A DESCRIPTION OF THE PROBLEM :
If we use the pattern z ('zz', 'zzzz'...) in the SimpleDateFormat to parse a date between 1900 and 1940, we noticed that we lost one hour(sometimes not exactly one hour).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
For example, this code will print 2 different hours:
Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.YEAR, 1900);
Date date = calendar.getTime();
DateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss yyyy zzz");
dateFormat.setLenient(false);
String strValue = dateFormat.format(date);
System.out.println(strValue + ", t = " + date.getTime());
try {
Date date2 = dateFormat.parse(strValue);
String strValue2 = dateFormat.format(date2);
System.out.println(strValue2 + ", t = " + date2.getTime());
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
We tried the code on another platform
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc))
and it works.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Why we assume it's a bug is that the problem seems to happen only between 1900 and 1940.
Hopefully the date parsing won't loose one hour.
ACTUAL -
result of the code above:
mer. oct. 31 10:24:18 1900 CET, t = -2182772702192
mer. oct. 31 09:33:39 1900 CET, t = -2182775742000
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
package com.bug.test;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
public class TestDate {
/**
* @param args
*/
public static void main(String[] args) {
Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.YEAR, 1900);
Date date = calendar.getTime();
DateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss yyyy z");
dateFormat.setLenient(false);
String strValue = dateFormat.format(date);
System.out.println(strValue + ", t = " + date.getTime());
try {
Date date2 = dateFormat.parse(strValue);
String strValue2 = dateFormat.format(date2);
System.out.println(strValue2 + ", t = " + date2.getTime());
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
---------- END SOURCE ----------
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20060421 (SR5) (JIT enabled: jitc))
and
java version "1.4.2_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_14-b05)
Java HotSpot(TM) Client VM (build 1.4.2_14-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 2.4.21-20.EL #1 Wed Aug 18 20:58:25 EDT 2004 i686 i686 i386 GNU/Linux
Windows XP Professional Version 2002 Service Pack 2
A DESCRIPTION OF THE PROBLEM :
If we use the pattern z ('zz', 'zzzz'...) in the SimpleDateFormat to parse a date between 1900 and 1940, we noticed that we lost one hour(sometimes not exactly one hour).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
For example, this code will print 2 different hours:
Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.YEAR, 1900);
Date date = calendar.getTime();
DateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss yyyy zzz");
dateFormat.setLenient(false);
String strValue = dateFormat.format(date);
System.out.println(strValue + ", t = " + date.getTime());
try {
Date date2 = dateFormat.parse(strValue);
String strValue2 = dateFormat.format(date2);
System.out.println(strValue2 + ", t = " + date2.getTime());
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
We tried the code on another platform
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc))
and it works.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Why we assume it's a bug is that the problem seems to happen only between 1900 and 1940.
Hopefully the date parsing won't loose one hour.
ACTUAL -
result of the code above:
mer. oct. 31 10:24:18 1900 CET, t = -2182772702192
mer. oct. 31 09:33:39 1900 CET, t = -2182775742000
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
package com.bug.test;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
public class TestDate {
/**
* @param args
*/
public static void main(String[] args) {
Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.YEAR, 1900);
Date date = calendar.getTime();
DateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss yyyy z");
dateFormat.setLenient(false);
String strValue = dateFormat.format(date);
System.out.println(strValue + ", t = " + date.getTime());
try {
Date date2 = dateFormat.parse(strValue);
String strValue2 = dateFormat.format(date2);
System.out.println(strValue2 + ", t = " + date2.getTime());
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
---------- END SOURCE ----------
- duplicates
-
JDK-4255109 (tz) TimeZone should support historical time zone name changes
-
- Open
-