StdDateFormat fails to parse 'zulu' date when TimeZone other than UTC

[brenuart]

The StdDateFormat fails to properly parse 'zulu' dates when the ObjectMapper has its timezone set to other than UTC. It appears the parser removes the trailing Z when found and construct a new java.util.Date instance using the timezone of the mapper instead of forcing it to UTC.

The example below illustrates the problem. It parses the representation of EPOCH in zulu format once with the mapper in its default configuration and a second time with its timezone set to GMT+1.
Because the trailing Z should be considered as a UTC timezone indicator, both cases should lead to the same date which is not the case.

String json = "\"1970-01-01T00:00:00.000Z\"";

// Standard mapper with timezone UTC
ObjectMapper mapper = new ObjectMapper();
Date dateUTC = mapper.readValue(json, Date.class);  // 1970-01-01T00:00:00.000+00:00

// Mapper with timezone GMT+1
mapper.setTimeZone(TimeZone.getTimeZone("GMT+1"));
Date dateGMT1 = mapper.readValue(json, Date.class);  // 1969-12-31T23:00:00.000+00:00

// Both dates should be the same
Assert.assertEquals(dateUTC.getTime(), dateGMT1.getTime());  // FAIL

[cowtowncoder]

And tested against version... ?

Yes, from test handling does look incorrect.

[cowtowncoder]

Tested with master (~2.9.0.pr3) and test fails.

[brenuart]

Issue detected with jackson-databind:2.8.8

[cowtowncoder]

@brenuart Thank you, makes sense. I assume it has been occurring throughout 2.x... but seems odd, I thought such an obvious case had been tested against.

[brenuart]

@cowtowncoder We were surprised too... Hopefully you reacted quickly ;-) Thx.
Want a PR for this ?

[cowtowncoder]

@brenuart Thanks -- I figured it out. It's sort of obvious in hindsight: since JDK does (did?) not support Z, SimpleDateFormat used marks Z as literal to match, but then code configures Jackson timezone instead, causing strong results. Fix will be in 2.8.9, which I hope to get out relatively soon, along with 2.9.0.pr4.