<i18n dev> java 9 AKST timezone parsing

[Rachna Goel]

Hi Naoto,

I digged into this issue today, and find that those time zone names 
which getting retrieved from TimeZoneNames_en.java are actually 
supplemented from COMPAT's TimeZoneNames.java.

COMPAT's TimeZoneNames.java has entries like

             {"SystemV/YST9", AKST},
             {"SystemV/YST9YDT", AKST},

which are then filled to CLDR's TimeZoneNames_en.java as  { 
"SystemV/YST9", Alaska }, by CLDRConverter during build time.

I am not sure how this could be a regression?

Do you have any idea of  when we did start supplementing time zone names 
from COMPAT or it exists since cldrconverter was pushed in?

Thanks,

Rachna


On 23/10/17 11:26 PM, Naoto Sato wrote:
> https://bugs.openjdk.java.net/browse/JDK-8189784
>
> Naoto
>
> On 10/19/17 11:57 AM, Clément Guillaume wrote:
>> 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 
>> <mailto: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> <mailto: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").parse("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").parse("2017-09-13T06:30:33.123America/Anchorage");
>>               > System.out.println(temporalAccessor);
>>               > 
>> System.out.println(isoFormatter.format(temporalAccessor));
>>               > }
>>               >
>>               > }
>>               >
>>
>>

-- 
Thanks,
Rachna