-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.12.0-rc1] Can no longer serialize using different timezones on independent OffsetDateTime fields #188
Comments
@WolfEkk quick question: by "producing different offset formats " do you mean that pattern specified with |
That's a good question, maybe I didn't stop to understand it entirely. I think it is as you suspect, it's just using the timezone configured in the mapper. I see the tests were a bit lousy in keeping them easy to follow, sorry I based them of off other tests that had broke (those tests had a bit of a different aim). Perhaps it's easier to read if I break it down a bit (I'm attaching the full working tests instead of pasting them fully here just the test files zipped, working maven project zipped). Given three values:
The following POJO:
Would be expected to output (it's what we get in
|
Ok, so it sounds like what I thought it did -- that offset/timezone included in value itself would not be used (by default), and that mapper-default offset is used instead; or, if specified, This is bit of a challenge as I can see why either method could make sense. Adding a @kupci WDYT? |
Need to think about this a bit, first thought is to follow some precedence, to use offset/timezone included in the value, unless overridden, perhaps |
@kupci I am not big fan of just adding As to |
I added |
Hi @cowtowncoder
Output:
|
A few questions:
|
@cowtowncoder Thanks, I created a new issue at #228 |
Hi it would seem like #185 (PR for #175) removes the possibility of producing different offset formats with the same ObjectMapper.
In the example below you will see 3 cases:
offset
field.offset2
field.None of these options seem to work. I think it might just be necessary to honor the given object's timezone when the timezone of the ObjectMapper is not set, I would love to hear your opinion on this or if there's an alternate way to make this work I would also love to hear about it.
I've added a fourth test case which shows that deserialization is possible when using
DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE
. This makes me think that at a higher level the change introduces asymmetry in the behavior, and I think being able to go back and forth preserving the data is important.Please let me know if I can improve this report or assist in any way.
The text was updated successfully, but these errors were encountered: