On Wed, 3 Jun 2026 14:52:49 GMT, Sruthy Jayan <[email protected]> wrote:
>> Modern AIX7+ supports full POSIX TZ format (e.g., >> TZ=CET-1CEST,M3.5.0,M10.5.0), but the current implementation in >> mapPlatformToJavaTimezone() searches the tzmappings file using the complete >> string including DST transition rules. The tzmappings file only contains the >> base timezone identifier (e.g., CET-1CEST), causing the lookup to fail and >> fall back to GMT offset calculation. >> >> This behavior differs from earlier AIX versions and IBM Java 8, which >> truncated the TZ string at the first comma before performing the lookup, >> successfully mapping to proper IANA timezone IDs. >> >> >> Fix include the below : >> Refactor the AIX timezone mapping implementation to support both modern and >> legacy POSIX TZ formats: >> >> Extract mapping logic into new getJavaTimezoneFromPlatform() helper function >> Implement two-phase lookup strategy: >> Phase 1: Attempt to map the full POSIX TZ string (supports modern AIX7+) >> Phase 2: If no match, truncate at first comma and retry (maintains backward >> compatibility) >> Fall back to GMT offset only if both lookups fail >> >> Exclude AIX from CustomTzIDCheckDST.java (validates POSIX DST rules directly) >> Add new AIXTzMappingTest.java to validate AIX-specific behavior: >> Successful mapping: CET-1CEST,M3.5.0,M10.5.0 → Europe/Paris >> Successful mapping: MEZ-1MESZ,M3.5.0,M10.5.0/3 → Europe/Berlin >> GMT fallback: Unknown timezone → GMT+HH:MM >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Sruthy Jayan has updated the pull request incrementally with one additional > commit since the last revision: > > Updated the bug id in the testcase > > Signed-off-by: Sruthy Jayan <[email protected]> Separation of the test looks good. A few comments on the newly added test. test/jdk/java/util/TimeZone/AIXTzMappingTest.java line 83: > 81: "Expected IANA timezone ID but got GMT offset: " + tzId + > 82: " for TZ=" + tzStr); > 83: } This only verifies that the fallback did not produce a GMT-offset ID. Since the test comments name the expected mappings, could this assert the exact mapped IDs instead, e.g. CET-1CEST,... -> Europe/Paris and MEZ-1MESZ,... -> Europe/Berlin? test/jdk/java/util/TimeZone/AIXTzMappingTest.java line 85: > 83: } > 84: // Verify DST transitions work correctly > 85: // For CET/MEZ: Standard time = GMT+1, DST = GMT+2 This does not seem to verify DST transitions (seen in other locations too); it only checks the current date/time. Maybe this should say that it verifies the current mapped timezone behavior. test/jdk/java/util/TimeZone/AIXTzMappingTest.java line 88: > 86: if (tz.inDaylightTime(time)) { > 87: // We are in Daylight savings period - expect GMT+02:00 > 88: if (time.toString().contains("GMT+02:00") || Since the test rejects tzId values starting with "GMT" above, is the GMT+02:00 case expected to be reachable here? If not, this condition seems unnecessary. test/jdk/java/util/TimeZone/AIXTzMappingTest.java line 97: > 95: } else { > 96: // Standard time - expect GMT+01:00 > 97: if (time.toString().contains("GMT+01:00") || Same here: after rejecting GMT-offset timezone IDs above, accepting GMT+01:00 in the string output seems unnecessary and a bit inconsistent with the purpose of this test. ------------- PR Review: https://git.openjdk.org/jdk/pull/31270#pullrequestreview-4420970633 PR Review Comment: https://git.openjdk.org/jdk/pull/31270#discussion_r3350511038 PR Review Comment: https://git.openjdk.org/jdk/pull/31270#discussion_r3350516627 PR Review Comment: https://git.openjdk.org/jdk/pull/31270#discussion_r3350520620 PR Review Comment: https://git.openjdk.org/jdk/pull/31270#discussion_r3350524238
