Re: java 9 AKST timezone parsing
(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)); }
}
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@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)); }
}
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@oracle.com <mailto:naoto.sato@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)); > } > > } >
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@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@oracle.com <mailto: naoto.sato@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)); > } > > } >
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@oracle.com <mailto:naoto.sato@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@oracle.com <mailto:naoto.sato@oracle.com> <mailto:naoto.sato@oracle.com <mailto:naoto.sato@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)); > } > > } >
participants (2)
-
Clément Guillaume
-
Naoto Sato