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:
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:
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 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 toDate(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 aDate
. As a result, thecalendar's
date-time fields and theTimeZone
value may have been overwritten, depending on subclass implementations. AnyTimeZone
value that has previously been set by a call tosetTimeZone
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.
This is due to a bug in Android 2.1 (API 7). It seems that Android programmers missed some undocumented Java behavior (which is classified as an unfixable bug itself!) in their implementation of Android 2.1.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With