<i18n dev> java 9 AKST timezone parsing

[Clément Guillaume]

I posted it few days ago (and got the id 9051213). I think it's still being
reviewed.

2017-10-11 17:11 GMT-07:00 Naoto Sato <naoto.sato at oracle.com>:

> Yes. Please go ahead and file a bug report. Thanks.
>
> Naoto
>
> On 10/11/17 5:04 PM, Clément Guillaume wrote:
>
>> Hi,
>>
>> I verified that using java.locale.providers=COMPAT with java 9 makes the
>> AKST to be parsed as America/Juneau
>>
>> Is http://bugreport.java.com/ the correct way to file a jira?
>>
>> Le mer. 11 oct. 2017 à 10:50, Naoto Sato <naoto.sato at oracle.com <mailto:
>> naoto.sato at oracle.com>> a écrit :
>>
>>     (replying to appropriate aliases, instead of generic jdk9-dev alias)
>>
>>     Hi Clément,
>>
>>     The locale data, where those time zone names are derived from, have
>> been
>>     switched to use Unicode Consortium's CLDR, instead of the ones that
>> are
>>     previously used prior to JDK9. So there will be some differences you
>> may
>>     encounter. However it seems not right to parse "AKST" to SystemV time
>>     zone. I'd appreciate it if you file a JIRA issue for this.
>>
>>     In the mean time, you can revert to the JDK8 behavior by setting the
>>     system property "-Djava.locale.providers=COMPAT" to the command line.
>>
>>     HTH,
>>     Naoto
>>
>>     On 10/10/17 7:37 PM, Clément Guillaume wrote:
>>      > Hello,
>>      >
>>      > When parsing a date time string that contains a time zone like
>>     AKST, AKDT,
>>      > HST or AST with a DateTimeFormatter built from a pattern
>>     containing 'z',
>>      > java 9 returns the SystemV variant of those timezone, which then
>>     behave
>>      > differently as the "modern" ones. Looks like it's also an issue
>>     with long
>>      > time zone ("Alaska Standard Time")
>>      >
>>      >  From my digging I noticed that the PrefixTree generated
>>      > by ZoneTextPrinterParser.getTree is different in java 8 and java
>>     9, and
>>      > this may be caused by a different order in the content returned
>>      > by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
>>      >
>>      > Is this an expected behavior of java 9? (other american time
>>     zones are
>>      > parsed to the modern version: PST -> America/Los_Angeles)
>>      >
>>      > I tested it with java 9 build 9+181 and java 8 build
>>     1.8.0_131-b11 (both
>>      > linux 64 with en_US as local) on this code:
>>      >
>>      > import java.time.ZoneOffset;
>>      > import java.time.format.DateTimeFormatter;
>>      > import java.time.temporal.TemporalAccessor;
>>      >
>>      > public class Main{
>>      >
>>      > public static void main(String[] args){
>>      > DateTimeFormatter timezoneFormatter =
>>     DateTimeFormatter.ofPattern("z");
>>      > TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST"
>> );
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("AKDT");
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("HST");
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("AST");
>>      > System.out.println(temporalAccessor);
>>      >
>>      > DateTimeFormatter isoFormatter =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(
>> ZoneOffset.UTC);
>>      > temporalAccessor =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").pa
>> rse("2017-09-13T06:30:33.123AKST");
>>      > System.out.println(temporalAccessor);
>>      > System.out.println(isoFormatter.format(temporalAccessor));
>>      > temporalAccessor =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").p
>> arse("2017-09-13T06:30:33.123America/Anchorage");
>>      > System.out.println(temporalAccessor);
>>      > System.out.println(isoFormatter.format(temporalAccessor));
>>      > }
>>      >
>>      > }
>>      >
>>
>>