Unexpected behavior with setTimeZone and ISO8601 parsing

I am using objectMapper.setTimeZone(TimeZone.getTimeZone("CET")) to alter the output of timezones when using objectMapper.configure(SerializationConfig.Feature.WRITE_DATES_AS_TIMESTAMPS, false);. This all works fine, but it seems that specifying a timezone also causes Jackson to misinterpret the Z in incoming ISO8601 times. The following testcase describes this issue:

@Test
public void testBehavior() {
  ObjectMapper objectMapper = new ObjectMapper();

  objectMapper.setTimeZone(TimeZone.getTimeZone("CET"));

  String time = "2016-01-01T17:00:00.000Z";
  Date dateAccordingToJackson = objectMapper.convertValue(time, Date.class);
  Date correctDate = Date.from(Instant.from(DateTimeFormatter.ISO_DATE_TIME.parse(time)));

  Assert.assertEquals("Demonstrate Jackson bug(?)", correctDate.toString(),
      dateAccordingToJackson.toString());
}

With the following output:

Demonstrate Jackson bug(?) expected:<Fri Jan 01 1[8]:00:00 CET 2016> but was:<Fri Jan 01 1[7]:00:00 CET 2016>

It seems to me that this is incorrect behavior since as far as I know ISO8601 mandates that a trailing Z indicates the time is transmitted in the UTC timezone. The documentation does say it affects all timezone behavior, but I don’t think this should be happening.

I’ve tested with Jackson 2.7.2

[ecarloslr]

I noticed this issue while using StdDateFormat, the cause is that DATE_FORMAT_STR_ISO8601_Zuses "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" as the format to use when the date comes with a Z. Notice that the Z is considered a literal, meaning it will be ignored completely.

When cloning the object for this pattern the CET TimeZone is used, and thus when parsing the date it will be interpreted in the CET TimeZone.

I believe the solution is to use DEFAULT_TIMEZONE (UTC) instead of _timezone when cloning DATE_FORMAT_ISO8601_Z.

[cowtowncoder]

Adding suggested test shows that this has been fixed at some point: 2.9 and 2.10 branches pass at least. Will add unit test in 2.10, close this issue.