exceptionfactory commented on PR #10011: URL: https://github.com/apache/nifi/pull/10011#issuecomment-2971468574
Thanks for following up on this issue @dan-s1. There are several things to consider when evaluating the `java.util.Date` behavior. The `toDate()` function returns a `java.util.Date` instance, and the `Date.toString()` representation is what is shown in the table. Internally, the class represents information using a `long` field named `fastTime` and and internal calendar with associated zone information. The zone information is what appears when calling `Date.toString()`. The Time Zone argument to the `toDate()` function influences the behavior of the date parsing, previously `SimpleDateFormat` and now `DateTimeFormatter`. In both cases, however, the returned `java.util.Date` will display the local system time zone when using the `toString()` method. As you described in the Jira issue, formatting `java.util.Date` can be accomplished using the `format()` EL function. The `toInstant()` function is properly more understandable in terms of actual behavior, because the resolved value is always computed according to UTC, whereas `toDate()` is more relative to local system time. Glad to consider the issue further in Jira, but some of this is running into the issues inherent in `java.util.Date`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
