java/time/test/java/time/format/TestUTCParse fails on macstadium machines (expects UTC not PST)

smlambert commented 10 months ago

As mentioned in https://github.com/adoptium/aqa-tests/issues/4982#issuecomment-1894967658 and https://github.com/adoptium/aqa-tests/issues/4982#issuecomment-1903640265, java/time/test/java/time/format/TestUTCParse fails with the following error:

11:29:41  test test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(): failure
11:29:41  java.lang.AssertionError: expected [UTC−08:00] but found [PST]
11:29:41    at org.testng.Assert.fail(Assert.java:99)
11:29:41    at org.testng.Assert.failNotEquals(Assert.java:1037)
11:29:41    at org.testng.Assert.assertEqualsImpl(Assert.java:140)
11:29:41    at org.testng.Assert.assertEquals(Assert.java:122)
11:29:41    at org.testng.Assert.assertEquals(Assert.java:629)
11:29:41    at org.testng.Assert.assertEquals(Assert.java:639)
11:29:41    at test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(TestUTCParse.java:65)
11:29:41    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:29:41    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:29:41    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:29:41    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
11:29:41    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
11:29:41    at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
11:29:41    at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
11:29:41    at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
11:29:41    at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
11:29:41    at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
11:29:41    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
11:29:41    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
11:29:41    at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
11:29:41    at org.testng.TestRunner.privateRun(TestRunner.java:764)
11:29:41    at org.testng.TestRunner.run(TestRunner.java:585)
11:29:41    at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
11:29:41    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
11:29:41    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
11:29:41    at org.testng.SuiteRunner.run(SuiteRunner.java:286)
11:29:41    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
11:29:41    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
11:29:41    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
11:29:41    at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
11:29:41    at org.testng.TestNG.runSuites(TestNG.java:1069)
11:29:41    at org.testng.TestNG.run(TestNG.java:1037)
11:29:41    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
11:29:41    at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
11:29:41    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:29:41    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:29:41    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:29:41    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
11:29:41    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
11:29:41    at java.base/java.lang.Thread.run(Thread.java:829)
11:29:41  
11:29:41  ===============================================
11:29:41  java/time/test/java/time/format/TestUTCParse.java
11:29:41  Total tests run: 4, Passes: 3, Failures: 1, Skips: 0

To make it easy for the infrastructure team to repeat and diagnose, please answer the following questions:

test suite/name (e.g, BUILD_LIST, TARGET, CUSTOM_TARGET)? BUILD_LIST=openjdk, TARGET=jdk_custom, CUSTOM_TARGET=java/time/test/java/time/format/TestUTCParse.java
a link into recent Test_ job on https://ci.adoptium.net which showed the failure https://ci.adoptium.net/job/Test_openjdk11_hs_extended.openjdk_aarch64_mac_testList_0/90/
Hyperlink to re-run in Grinder:
- rerun link
Is there an existing issue elsewhere covering this? No
Which machine(s) does it work on? orka agents
Which machine(s) does it fail on? test-macstadium-macos11-arm64-2 (possibly others)

Any other details: see console output above

sxa commented 10 months ago

Related: Top level issue at https://github.com/adoptium/infrastructure/issues/2662, and the orka issue at https://github.com/adoptium/infrastructure/issues/2536

sxa commented 3 weeks ago

Need to verify if this fails on the orka machines, and then decide what to do if it still fails on any of our existing statically provisiioned systems (e.g. macincloud)

sxa commented 1 week ago

Attempting re-run on the orka nodes at https://ci.adoptium.net/job/Grinder/11427/ but it fell foul of https://github.com/adoptium/infrastructure/issues/3814

sxa commented 1 week ago

Also testing on x64 at:

G#11429 on test-macstadium-1014 cross ❌ cross
G#11430 on macincloud-1201-1 tick ✅
G#11431 on orka node (Fell back to macstadium1014 due to https://github.com/adoptium/infrastructure/issues/3814) ❌
G#11494 on orka (albeit on an arm one) ✅

sxa commented 1 week ago

Honestly wondering if this is something specific to macos 10 at the moment. This reproducer shows that it is giving a "local" timezone (i.e. PST if using the code below, or GMT if you use Europe/London) instead of a UTC offset:

import java.time.*;
import java.time.format.*;
import java.util.Locale;

public class utc
{
    public static void main(String [] args) 
    {
        var fmt = DateTimeFormatter.ofPattern("z", Locale.FRANCE);
        var zdt = ZonedDateTime.of(2023, 3, 3, 0, 0, 0, 0, ZoneId.of("America/Los_Angeles"));
        System.out.println("Expecting UTC\u221208:00, got "+fmt.format(zdt));
    }
}

sxa commented 1 week ago

Noting that this is the same failure which has been seen in https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210967471 and the test has been excluded for Temurin runs. The notes in there also indicate that it's a test which has been removed from newer JDKs.

(Noting for historic reference that this test is NOT impacted by the TZ setting in the environment)

sxa commented 1 week ago

@Haroon-Khel Is there a reason why the PR to exclude this was done on linux-all and not macos too since it was seen there too in your issue?

Haroon-Khel commented 1 week ago

iirc I excluded it on linux only as that was the platform I was running tests on. I think it should also be excluded on MacOS since it was agreed that the test itself does not handle timezones well

Haroon-Khel commented 1 week ago

Exclude pr https://github.com/adoptium/aqa-tests/pull/5766

adoptium / infrastructure

java/time/test/java/time/format/TestUTCParse fails on macstadium machines (expects UTC not PST) #3361