JDK-6609362 : (tz) Epoch GMT offset causes unexpected behaviour in SimpleDateFormat parsing
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-09-26
  • Updated: 2010-07-29
  • Resolved: 2007-12-26
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
GMT timezone

A DESCRIPTION OF THE PROBLEM :
Olsen states that at the time of the epoch, the GMT offset was +1.  This means that Dates created as "new Date(0L)" appear as "Thu Jan 01 01:00:00 GMT 1970".

However, date-parsing via SimpleDateFormat does not take this offset into account when interpreting dates either to or from Strings, resulting in unexpected and (believed) incorrect behaviour.

(Please see bug report 4832236 for background to the new Date(0L) behaviour.)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Construct a Date at the epoch.  Format this Date as a String, then parse this String back into a Date - the date will have shifted by +1 hour.

The attached test-case constructs a Date at the epoch, then repeatedly transforms it to a String and back.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Even though it was converted via a String-representation, the date should not have changed.
ACTUAL -
Each format/parse cycle shifts the date by +1 hour.  Exact output from test-case is as follows:

Thu Jan 01 01:00:00 GMT 1970
Thu Jan 01 02:00:00 GMT 1970
Thu Jan 01 03:00:00 GMT 1970
Thu Jan 01 04:00:00 GMT 1970
Thu Jan 01 05:00:00 GMT 1970
Thu Jan 01 06:00:00 GMT 1970
Thu Jan 01 07:00:00 GMT 1970
Thu Jan 01 08:00:00 GMT 1970
Thu Jan 01 09:00:00 GMT 1970
Thu Jan 01 10:00:00 GMT 1970

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.SimpleDateFormat;
import java.util.Date;

public class EpochDateShiftTest {
	public static void main(String[] args) throws Exception {
		final SimpleDateFormat sdf = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy");
		Date date = new Date(0L);
		
		for (int i = 0; i < 10; i++) {
			System.out.println(date.toString());
			date = sdf.parse(sdf.format(date));
		}
	}
}

---------- END SOURCE ----------

Comments
WORK AROUND Please use Z to format and parse historical time zone offset changes to avoid confusions with historical time zone name changes. import java.util.*; import java.text.*; public class Test { public static void main(String[] args) throws ParseException { TimeZone.setDefault(TimeZone.getTimeZone("Europe/London")); SimpleDateFormat f = new SimpleDateFormat("EEE MMM dd HH:mm:ss Z yyyy"); Date d = new Date(0); for (int i = 0; i < 10; i++) { String s = f.format(d); System.out.println(s); d = f.parse(s); } } } output: Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970 Thu Jan 01 01:00:00 +0100 1970
26-12-2007

EVALUATION This is a known limitation of TimeZone.getDisplayName that does not support historical name changes. During 1968-10-27 to 1971-10-31, the time zone offset is +0100 in Europe/London and its time zone name should be "BST". Closing this CR as a duplicate of 4255109.
26-12-2007