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.s...@oracle.com
<mailto:naoto.s...@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.s...@oracle.com
<mailto:naoto.s...@oracle.com> <mailto:naoto.s...@oracle.com
<mailto:naoto.s...@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
