Open Haroon-Khel opened 1 month ago
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.
The jobs in the links have expired, Ill run some more to get a fresh output
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)
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)
It looks like the static containers are already set to UTC. On test-docker-ubuntu2404-x64-1, on which the test failed https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210979626
root@e80f94f22a13:~# date
Fri Jul 5 15:01:20 UTC 2024
root@e80f94f22a13:~# date +"%Z %z"
UTC +0000
root@e80f94f22a13:~#
Reiterating my comment in https://github.com/adoptium/infrastructure/issues/3614#issuecomment-2218082829
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 https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2211063655
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 https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210967471
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
EDIT: Only failed on s390x with the same error log as https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210967471
Noting that this is the only machine of the set that is not a docker image 🤔
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
ref https://github.com/adoptium/infrastructure/issues/3614#issuecomment-2187110622
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 https://github.com/adoptium/infrastructure/issues/3501#issuecomment-2167782850
UBI8 and 9 JDK11 https://github.com/adoptium/infrastructure/issues/3586#issuecomment-2176380667
We are not seeing it fail on other linux platforms
Mac aarch64 JDK11 Jan 2024 release triage https://github.com/adoptium/aqa-tests/issues/4982#issuecomment-1894967658