[
https://issues.apache.org/jira/browse/NIFI-13972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896008#comment-17896008
]
David Handermann commented on NIFI-13972:
-----------------------------------------
Thanks for highlighting the parseBest() behavior [~tpalfy] and running the
performance comparison [~turcsanyip].
Setting a zone on the DateTimeFormatter instance could be problematic due to
the shared registry of instances.
The fundamental difficulty is attempting to determine whether the specified
pattern includes a timezone component, given the variety of formatting
approaches.
Another approach would be to perform more granular time unit queries on an
unresolved TemporalAccessor. The parseBest() method is a brute-force attempt to
do that, but given the performance implications, this looks like it is worth
revisiting. I think it should be possible include some logic that looks for a
time zone component in the unresolved TemporalAccessor, and then decide whether
to build a ZonedDateTime or LocalDateTime object.
I will take a look at that approach to consider the implications, and I'm open
to additional options.
> ObjectLocalDateTimeFieldConverter.convertField ignores time zone
> ----------------------------------------------------------------
>
> Key: NIFI-13972
> URL: https://issues.apache.org/jira/browse/NIFI-13972
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Tamas Palfy
> Assignee: Tamas Palfy
> Priority: Major
>
> When the incoming value is a string that contains timezone/offset information
> the returned LocalDateTime simply ignores that part and returns a value as if
> it was in the local timezone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
