Question

I’ve been trying to isolate a bug in my application. I succeeded in producing the following “riddle”:

SimpleDateFormat f1 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
SimpleDateFormat f2 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
Date d = f1.parse("2012-01-01T00:00:00+0700");
String s1 = f1.format(d); // 2011-12-31T18:00:00+0700
String s2 = f2.format(d); // 2011-12-31T18:00:00+0100

I get the values in comments when I run this code on Android API 7 (yes, really). This behavior depends on particular Java implementation.

My questions are:

• Why s1 does not equal s2?
• And more importantly, why s1 is incorrect? While s2 points to a proper point in time, s1 does not. There seems to be a bug in Android’s SimpleDateFormat implementation.

ANSWER TO QUESTION 1: See the answer by BalusC:

• [After using SimpleDateFormat#parse] any TimeZone value that has previously been set by a call to setTimeZone may need to be restored for further operations.

ANSWER TO QUESTION 2: See the answer by wrygiel (myself).

• This is due to a bug in Android 2.1 (API 7).

Answer 1

This is mentioned in javadoc of DateFormat#parse():

Parse a date/time string according to the given parse position. For example, a time text "07/10/96 4:5 PM, PDT" will be parsed into a Date that is equivalent to Date(837039900000L).

By default, parsing is lenient: If the input is not in the form used by this object’s format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).

This parsing operation uses the calendar to produce a Date. As a result, the calendar's date-time fields and the TimeZone value may have been overwritten, depending on subclass implementations. Any TimeZone value that has previously been set by a call to setTimeZone may need to be restored for further operations.

Note the last paragraph. It unfortunately doesn’t explain when exactly this will occur. To fix your particular problem you need to explicitly set the desired timezone before the formatting operation.

As to the mutability of SimpleDateFormat itself, this is known for years. You should never create and assign an instance of it as a static or class variable, but always as a method (threadlocal) variable.