Skip to content

[LOG4J2-3805] NamedInstantPatternTest#compatibilityOfLegacyPattern fails in timezones with minute offsets (e.g., GMT+05:30) #3888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: 2.x
Choose a base branch
from

Conversation

ramanathan1504
Copy link
Contributor

@ramanathan1504 ramanathan1504 commented Aug 19, 2025

The compatibilityOfLegacyPattern test fails in timezones with fractional offsets
(e.g., Asia/Kolkata). This happens because SimpleDateFormat truncates fractional
offsets (+05:30 → +05) while DateTimeFormatter preserves them.

This change skips the test in such environments, ensuring consistent builds.

fix #3885

…imezone offsets

The compatibilityOfLegacyPattern test fails in environments where the system
default timezone has a non-zero minute offset (e.g., Asia/Kolkata, Asia/Kathmandu).

Root cause:
- SimpleDateFormat's X pattern truncates fractional offsets (e.g., +05:30 → +05).
- DateTimeFormatter's X pattern preserves the minutes (+05:30).

Since Log4j intentionally follows DateTimeFormatter’s behavior, the test should
not assert equivalence in such environments.

This change adds an assumption to skip the test when the system timezone offset
is not a whole hour. This ensures deterministic builds for contributors in all
regions, while still verifying correctness in whole-hour zones.

Closes apache#3805
@ramanathan1504 ramanathan1504 changed the title [LOG4J2-3805] Skip compatibilityOfLegacyPattern test for fractional timezone offsets [LOG4J2-3805] NamedInstantPatternTest#compatibilityOfLegacyPattern fails in timezones with minute offsets (e.g., GMT+05:30) Aug 19, 2025
@ppkarwasz ppkarwasz moved this from To triage to Ready in Log4j bug tracker Aug 19, 2025
Copy link

Job Requested goals Build Tool Version Build Outcome Build Scan®
build-macos-latest clean install 3.9.8 Build Scan PUBLISHED
build-ubuntu-latest clean install 3.9.8 Build Scan PUBLISHED
build-windows-latest clean install 3.9.8 Build Scan PUBLISHED
Generated by gradle/develocity-actions

Copy link
Contributor

@ppkarwasz ppkarwasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ramanathan1504,

Could you move the assumption to the beginning of the test, so it is easier to follow?

Comment on lines +46 to +55
if (namedPattern == NamedInstantPattern.ISO8601_OFFSET_DATE_TIME_HH) {
java.time.ZoneOffset offset =
java.time.ZoneId.systemDefault().getRules().getOffset(java.time.Instant.now());
Assumptions.assumeTrue(
offset.getTotalSeconds() % 3600 == 0,
() -> String.format(
"Skipping test: ISO8601_OFFSET_DATE_TIME_HH requires a whole-hour offset, but system offset is %s",
offset));
assertThat(legacy).isEqualTo(modern);
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assumption check should be the very first thing in the test. That way, if it fails, none of the setup or assertions will run. Since Assumptions.assumeTrue(...) throws an exception when the condition is not met, you don’t need to wrap later code in an if block — the test will be skipped automatically. This also makes the test flow easier to follow.

Nitpick: personally I prefer AssertJ over pure JUnit5. It also has an Assumptions class.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready
Development

Successfully merging this pull request may close these issues.

NamedInstantPatternTest#compatibilityOfLegacyPattern fails in timezones with minute offsets (e.g., GMT+05:30)
2 participants