RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails
Naoto Sato
naoto at openjdk.org
Mon Feb 3 22:21:10 UTC 2025
On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:
> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
>
>
> TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
> System.out.println(tz.getDisplayName());
> System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
> System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
>
>
> - Java 22 output:
>
>
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java
> Ecuador Time
> ECST
> ECT
>
>
> - Java 23 output:
>
>
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java
> Ecuador Time
> GMT-04:00
> GMT-05:00
>
>
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.
The benchmark was provided with the fix to https://bugs.openjdk.org/browse/JDK-8304976, and most likely the failure was due to the removal of COMPAT locale provider. Would you double check the benchmark is relevant with your fix? Since UTC is a special time zone, so I just wanted to double check. If we need more practical short name, "PST" might not be a bad choice
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632271474
More information about the core-libs-dev
mailing list