localized month names still not correct in 2.26.1 (#4129 marked as fixed in 2.26.1 release notes)

[xzel23]

Description

Issue #4129 was included in the release notes of 2.26.1, but I still observe incorrect formatting after upgrading to that version for these patterns:

        "%d{dd-MMMM-yyyy}{de-DE} %p %m%n",
        "%d{EEEE, dd. MMMM yyyy}{de-DE} %p %m%n",

I stepped into the Log4J code to make sure the correct Jar is used. Since I cannot reopen the original issue, I create a new one.

Configuration

Version: 2.26.1

Operating system: macOS 26.5.2

JDK: BellSoft Liberica-21.0.11-macos-aarch64-javafx

Logs

Excerpt from my unit test logs (SLB4J is my own backend that aims to provide a Log4J compatible pattern):

Discrepancies found:
Pattern: %d{dd-MMMM-yyyy}{de-DE} %p %m%n
Log4j: [10-July-2026 TRACE Trace message
]
SLB4J: [10-Juli-2026 TRACE Trace message
]
Pattern: %d{dd-MMMM-yyyy}{de-DE} %p %m%n
Log4j: [10-July-2026 DEBUG Debug message
]
SLB4J: [10-Juli-2026 DEBUG Debug message
]
Pattern: %d{dd-MMMM-yyyy}{de-DE} %p %m%n
Log4j: [10-July-2026 INFO Test message
]
SLB4J: [10-Juli-2026 INFO Test message
]
Pattern: %d{dd-MMMM-yyyy}{de-DE} %p %m%n
Log4j: [10-July-2026 WARN Warning message
]
SLB4J: [10-Juli-2026 WARN Warning message
]
Pattern: %d{dd-MMMM-yyyy}{de-DE} %p %m%n
Log4j: [10-July-2026 ERROR Error message
]
SLB4J: [10-Juli-2026 ERROR Error message
]
Expected :true
Actual   :false

Reproduction

Same as for #4129.

[ramanathan1504]

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:

%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!

[xzel23]

Hi @ramanathan1504 ,

thank you for the quick reply. That makes sense. I will uncomment these two test cases, document the difference, and add a new one for the new pattern you gave - that one is not yet handled correctly in my backend.

[ramanathan1504]

Hi @ramanathan1504 ,

thank you for the quick reply. That makes sense. I will uncomment these two test cases, document the difference, and add a new one for the new pattern you gave - that one is not yet handled correctly in my backend.

Thanks👍