ramanathan1504 commented on issue #4177:
URL:
https://github.com/apache/logging-log4j2/issues/4177#issuecomment-4932822264
Hi @xzel23,
In your original report (#4129), you mentioned: "I think it should either
work... or be documented."
We decided to go with the latter! If you check PR #4130, we updated the
documentation for the 2.26.1 release to clarify this behavior rather than
changing the Java parsing logic (which could introduce breaking changes for
others).
Regarding the discrepancies you found in your test suite (#4177) where
SLF4J/Logback correctly prints "Juli" but Log4j prints "July": this happens
because Log4j's DatePatternConverter arguments are strictly positional:
{pattern}
{timezone}
{locale}
When you use %d{dd-MMMM-yyyy}{de-DE}, Log4j strictly parses de-DE as the
timezone. Since it's invalid, it falls back to the system timezone, and with no
3rd argument provided, it falls back to the English system locale.
Because we only updated the documentation and didn't change the actual code,
you can just stick to your current version (2.26.0).
To fix your Log4j configuration so that your test passes and matches the
SLB4J output (without hardcoding {GMT}), you can dynamically pass your system's
timezone into that required 2nd position using a property lookup:
```Text
%d{dd-MMMM-yyyy}{${sys:user.timezone}}{de-DE} %p %m%n
```
This perfectly satisfies the Log4j parser and will give you the expected
10-Juli-2026 output. Hope this helps get your test suite passing!
--
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]
