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