java/time/test/java/time/format/TestUTCParse.java failing on multiple platforms for JDK11

[Haroon-Khel]

ref #3614 (comment)

We are seeing java/time/test/java/time/format/TestUTCParse.java fail on multiple platforms. We are not sure if the failure is machine specific (specific to a group of machines) or OS specific.

Ubuntu 2404 JDK11 #3501 (comment)

UBI8 and 9 JDK11 #3586 (comment)

We are not seeing it fail on other linux platforms

Mac aarch64 JDK11 Jan 2024 release triage adoptium/aqa-tests#4982 (comment)

[smlambert]

java.lang.AssertionError: expected [UTC−08:00] but found [PST] that was seen on Mac nodes is likely 'a test case that is expecting a certain machine configuration' issue, which means it a poorly written test case which could be addressed by updating the machine Date/Time preferences, but also the testcase itself could be adjusted to handle cases where Date/Time preference is not set to Coordinated Universal Time / UTC, but is instead using local time settings.

I do not see console output of the way in which the test fails on Linux in any of the issues linked. If it is failing with different stacktrace output, we need to understand why.

[Haroon-Khel]

The jobs in the links have expired, Ill run some more to get a fresh output

[Haroon-Khel]

Looking at https://ci.adoptium.net/job/Grinder/10507/console which is running on test-docker-ubi8-x64-1, we're seeing a similar output as the mac issue

15:20:22  test test.java.time.format.TestUTCParse.testUTCOffsetRoundTrip("UTC-01:30"): success
15:20:22  test test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(): failure
15:20:22  java.lang.AssertionError: expected [UTC−08:00] but found [PST]
15:20:22  	at org.testng.Assert.fail(Assert.java:99)
15:20:22  	at org.testng.Assert.failNotEquals(Assert.java:1037)

[Haroon-Khel]

Same on ubuntu2404 https://ci.adoptium.net/job/Grinder/10508/console

15:28:22  test test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(): failure
15:28:22  java.lang.AssertionError: expected [UTC−08:00] but found [PST]
15:28:22  	at org.testng.Assert.fail(Assert.java:99)
15:28:22  	at org.testng.Assert.failNotEquals(Assert.java:1037)
15:28:22  	at org.testng.Assert.assertEqualsImpl(Assert.java:140)

[Haroon-Khel]

It looks like the static containers are already set to UTC. On test-docker-ubuntu2404-x64-1, on which the test failed #3658 (comment)

root@e80f94f22a13:~# date
Fri Jul  5 15:01:20 UTC 2024
root@e80f94f22a13:~# date +"%Z %z"
UTC +0000
root@e80f94f22a13:~# 

[Haroon-Khel]

Reiterating my comment in #3614 (comment)

On test-docker-alpine319-x64-4 on which the test passes (https://ci.adoptium.net/job/Grinder/10549/console)

8f585a2be287:/# date
Tue Jul  9 15:57:37 UTC 2024
8f585a2be287:/# date +"%Z %z"
UTC +0000
8f585a2be287:/# 

Same format as #3658 (comment)

[Haroon-Khel]

Re the ubuntu2404 failures, rerunning the test on ubuntu2204 to check for a difference in failure

test-docker-ubuntu2204-x64-7 https://ci.adoptium.net/job/Grinder/10556/console
test-docker-ubuntu2204-armv8-1 https://ci.adoptium.net/job/Grinder/10557/console
test-marist-ubuntu2204-s390x-1 https://ci.adoptium.net/job/Grinder/10558/console
test-docker-ubuntu2204-ppc64le-3 https://ci.adoptium.net/job/Grinder/10559/console

EDIT: Only failed on s390x with the same error log as #3658 (comment)

[Haroon-Khel]

In the testcode, the failure is here https://github.com/adoptium/jdk11u/blob/1e3e6877d5c2eb53f9dbb4fc9e045d83975c84b1/test/jdk/java/time/test/java/time/format/TestUTCParse.java#L65

On a passing machine the formatted variable is UTC?08:00 while on a failing one it is PST

[sxa]

EDIT: Only failed on s390x with the same error log as #3658 (comment)

Noting that this is the only machine of the set that is not a docker image 🤔

[Haroon-Khel]

With Jie's help, taking a closer look at the test code, it does reveal that the test code is not handling the differences in CLDR between machines and that the test assumes CLDR will behave how the test expects it to https://github.com/adoptium/jdk11u/blob/1e3e6877d5c2eb53f9dbb4fc9e045d83975c84b1/test/jdk/java/time/test/java/time/format/TestUTCParse.java#L46

Assuming CLDR's SHORT name for "America/Los_Angeles"
        // produces "UTC\u212208:00"

which is not always the case.

The test is removed altogether in the latest jdk https://github.com/openjdk/jdk/blob/537d20afbff255489a7b1bdb0410b9d1aba715b7/test/jdk/java/time/test/java/time/format/TestUTCParse.java

Either way I do not think this is an infra problem, and perhaps the test should be excluded

[Haroon-Khel]

Since it was discussed that this test failure isnt an infra problem, but more so that the test code is not handling the differences in CLDR between machines well, I am going to close this issue. The test has already been excluded