ppkarwasz commented on issue #3885: URL: https://github.com/apache/logging-log4j2/issues/3885#issuecomment-3198267746
> [@ppkarwasz](https://github.com/ppkarwasz), unless you've objections, I'd like to close this issue as `Not planned`. This isn’t a bug in `FixedDateFormat`, because the [`SimpleDateFormat` documentation](https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html) explicitly uses Indian Standard Time as an example of the `X` pattern’s output: > For formatting, if the offset value from GMT is 0, "Z" is produced. If the number of pattern letters is 1, any fraction of an hour is ignored. For example, if the pattern is "X" and the time zone is "GMT+05:30", "+05" is produced. However, I believe this behavior in `SimpleDateFormat` is quite poorly chosen. Ignoring fractional offsets can lead to misleading results, for instance, a 30-minute meeting could appear shifted by half an hour simply because of the formatter’s rounding. This is most likely why `DateTimeFormatter` diverged from this convention, and it’s also why we should avoid replicating the `SimpleDateFormat` behavior here. Should we fix the test class to skip this case if the zone offset contains fractions of an hour? ```java if (namedPattern == NamedInstantPattern.ISO8601_OFFSET_DATE_TIME_HH) { ZoneOffset offset = ZoneId.systemDefault().getRules().getOffset(Instant.now()); Assumptions.assumeThat(offset.getTotalSeconds() % 3600) .describedAs("Skipping test: ISO8601_OFFSET_DATE_TIME_HH requires a whole-hour offset, but system offset is %s", offset) .isEqualTo(0); } ``` -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
