On Mon, 1 Jun 2026 16:45:36 GMT, Naoto Sato <[email protected]> wrote:
>> Sruthy Jayan has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Removed extra whitespaces >> >> Signed-off-by: Sruthy Jayan <[email protected]> > > Thanks for the explanation. I think this test and the AIX mapping change are > validating different things. > > The original test is not really proving that java.util.TimeZone preserves the > full POSIX TZ rule as a TimeZone. On non-AIX platforms the native code may > pass the TZ value through, but java.util.TimeZone only recognizes tzdb IDs > and custom GMT offset IDs. For a POSIX string such as > MEZ-1MESZ,M3.5.0,M10.5.0/3, the default TimeZone falls back to a GMT offset > based on the current platform offset. So the test is effectively a > current-offset smoke test against the explicit TZ rule. > > With the AIX change, however, the comma suffix is discarded and only the > prefix is mapped through tzmappings, e.g. CET-1CEST,M3.5.0,M10.5.0 -> > CET-1CEST -> Europe/Paris. That means the explicit POSIX transition rules are > no longer what determines the result. If that is the intended AIX behavior, > then this test seems no longer applicable to AIX. > > In that case, I think it would be clearer to exclude AIX from this test and > add a separate AIX-specific test for the tzmappings fallback behavior, rather > than changing this test to accept the mapped timezone result. Otherwise the > test summary/bug description should be updated, because it is no longer > validating that the explicit DST rules in TZ are honored on AIX. @naotoj As suggested : I’ve excluded CustomTzIDCheckDST.java for the AIX platform and added AIXTzMappingTest.java to validate AIX-specific behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31270#issuecomment-4613459368
