java 9 AKST timezone parsing
Naoto Sato
naoto.sato at oracle.com
Mon Oct 23 17:56:07 UTC 2017
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));
> > }
> >
> > }
> >
>
>
More information about the core-libs-dev
mailing list