<i18n dev> java 9 AKST timezone parsing

[Rachna Goel]

Kindly ignore my mail on subject matter.

It was sent by mistake.

Thanks,
Rachna


On 31/10/17 5:26 PM, Rachna Goel wrote:
>
> 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

-- 
Thanks,
Rachna