Skip to content

#166: Only normalize OffsetDateTimes when they are normalizable #172

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

Closed
wants to merge 1 commit into from

Conversation

morth
Copy link

@morth morth commented May 15, 2020

Possible fix for #166. This commit adds a check before the OffsetDateTime adjustment of ADJUST_DATES_TO_CONTEXT_TIME_ZONE that ensures that the OffsetDateTime is normalizeable given a specific time zone offset. When it is not, normalization is skipped and the un-adjusted OffsetDateTime is returned.

Possible fix for FasterXML#166. This commit adds a check before the OffsetDateTime adjustment of ADJUST_DATES_TO_CONTEXT_TIME_ZONE that ensures that the OffsetDateTime is normalizeable given a specific time zone offset. When it is not, normalization is skipped and the un-adjusted OffsetDateTime is returned.
@cowtowncoder
Copy link
Member

+1 for suggestion on static member. One other suggestion: if easy, rebasing against 2.11 (if considered safe change) or 2.12 (if there is risk) would be nice. That can then be merged forward 2.11 -> 2.12 -> master (3.0). Not a big deal as cherry-picking back from master is probably easy as well.

@morth
Copy link
Author

morth commented May 16, 2020

@kupci @cowtowncoder I implemented your suggestions and fixed this in 2.11 in #173.

@kupci 'Ex' was for "excluded", since it was the first value outside of the boundary.

@morth morth closed this May 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants