Closed ThorstenPlatz closed 9 years ago
Thank you for investigating with different versions, this is helpful. If it is easy enough, would it be possible to run one more test, with 2.4.6? While it is likely the problem exists (given that 2.5.3 fails, which has same fixes as 2.4.6), due to 2.4.4 causing breakage, there is a chance that fixes in 2.4.5 and 2.4.6 might be relevant. Breakage in question was related to incorrect caching of complex types like Map
s, so it is not immediately obvious that this problem would be related. But timing does appear suspicious.
Your guess was right!
The test passes with 2.4.6:
packageVersion: 2.4.6
jsonInstant: "2015-05-12T05:00:22.134Z"
jsonDateTime: "2015-05-12T05:00:22.134Z"
And also passes with 2.4.5:
packageVersion: 2.4.5
jsonInstant: "2015-05-12T05:08:09.180Z"
jsonDateTime: "2015-05-12T05:08:09.180Z"
I did not tried this version before, because it was not listed in the release notes.
Looks like I hadn't merged from 2.4. The actual fix is in jackson-databind
however, I think.
But this does raise the question of why 2.5.3 fails. It should have similar fixes...
So this was a regression due to changes meant to let Duration
serializer use feature WRITE_DURATIONS_AS_TIMESTAMPS
: accidentally was also using that for Instant
values, which should instead use older WRITE_DATES_AS_TIMESTAMPS
SerializationFeature
.
Thank you for reporting this!
The configured date/time format is not considered for org.joda.time.Instant since version 2.4.4 and newer. In earlier versions Instants were serialized using the configured formatter.
Reproduce with the follwing code snippet:
Output using v2.4.3:
Output using v2.4.4:
Output using v2.5.0:
Output using v2.5.3: