exceptionfactory commented on PR #10011: URL: https://github.com/apache/nifi/pull/10011#issuecomment-2981073123
> @exceptionfactory I do not mean to belabor this but I did not see the answer to my question earlier why the date and times are skewed for the other time zones. I understand why the UTC is present but shouldn't each of the time zones have the correct date and time per their timezone? Per you explanation I would still expect to see the following > Time Zone toDate result Expected Result > Europe/Berlin Sat May 31 22:00:00 UTC 2025 Sun Jun 01 02:00:00 UTC 2025 > UTC Sun Jun 01 00:00:00 UTC 2025 Sun Jun 01 00:00:00 UTC 2025 > Europe/Kiev Sat May 31 21:00:00 UTC 2025 Sun Jun 01 03:00:00 UTC 2025 > America/Detroit Sun Jun 01 04:00:00 UTC 2025 Sat May 31 20:00:00 UTC 2025 > @exceptionfactory I do not mean to belabor this but I did not see the answer to my question earlier why the date and times are skewed for the other time zones. I understand why the UTC is present but shouldn't each of the time zones have the correct date and time per their timezone? Per you explanation I would still expect to see the following > Time Zone toDate result Expected Result > Europe/Berlin Sat May 31 22:00:00 UTC 2025 Sun Jun 01 02:00:00 UTC 2025 > UTC Sun Jun 01 00:00:00 UTC 2025 Sun Jun 01 00:00:00 UTC 2025 > Europe/Kiev Sat May 31 21:00:00 UTC 2025 Sun Jun 01 03:00:00 UTC 2025 > America/Detroit Sun Jun 01 04:00:00 UTC 2025 Sat May 31 20:00:00 UTC 2025 The apparent skew is the result of interpreting the input time zone offset relative to the system local time zone. This gets back to the behavior of `java.util.Date`. During parsing, the `parseToInstant` method computes a `LocalDateTime`, then adjusts it based on the input Time Zone argument. After that adjustment, `Date.from()` takes the epoch time in milliseconds from the parsed `java.time.Instant`. Due to the way that `java.util.Date` always computes `toString()` relative to the system default Time Zone, the string representation is also adjusted. This gets back to the fundamental problems with `java.util.Date` that prompted to move to more precise classes in the `java.time` package. -- 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]
