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>: > 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>> 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)); >> > } >> > >> > } >> > >> >>
