From naoto.sato at oracle.com  Wed Oct 11 17:50:28 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Oct 2017 10:50:28 -0700
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
Message-ID: <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>

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

From naoto.sato at oracle.com  Thu Oct 12 00:11:24 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Oct 2017 17:11:24 -0700
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
Message-ID: <b3771125-0d5a-aca1-47e8-7f163c4565f0@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>> 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));
>      > }
>      >
>      > }
>      >
> 

From clement at guillaume.bzh  Thu Oct 12 00:04:56 2017
From: clement at guillaume.bzh (=?UTF-8?Q?Cl=C3=A9ment_Guillaume?=)
Date: Thu, 12 Oct 2017 00:04:56 +0000
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
Message-ID: <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>

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

From brent.christian at oracle.com  Thu Oct 12 18:52:16 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 12 Oct 2017 11:52:16 -0700
Subject: <i18n dev> RFR 8187772 : JVM crash when currency set on MacOS 10.10
	and earlier
Message-ID: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>

Hi,

Please review my change to prevent a startup crash on earlier versions 
of MacOS.

    Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/

When a non-default currency is set in the Language & Region control 
panel, it's reflected as a variant in the locale identifier string.  For 
example, "en_US at currency=RUB" for U.S. English using the Russian rubles 
currency.

convertToPOSIXLocale() is not expecting such variants, nor such a long 
string.  The result is a SEGV from memmove() on line 161.  (Additional 
details are in the bug report.)

The fix truncates the string passed to convertToPOSIXLocale() before any 
'@'-denoted variant tags.

FWIW, the crash only happens on MacOS 10.10 and earlier because later 
versions of MacOS always return a region along with the language (line 
65), so we don't need to query the locale identifier (line 84) to 
determine the region (hyphenPos is never NULL on line 82).

Thanks,
-Brent

From naoto.sato at oracle.com  Thu Oct 12 19:38:16 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 12 Oct 2017 12:38:16 -0700
Subject: <i18n dev> RFR 8187772 : JVM crash when currency set on MacOS
 10.10 and earlier
In-Reply-To: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
Message-ID: <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>

Looks fine, Brent.

Naoto

On 10/12/17 11:52 AM, Brent Christian wrote:
> Hi,
> 
> Please review my change to prevent a startup crash on earlier versions 
> of MacOS.
> 
>  ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
> 
> When a non-default currency is set in the Language & Region control 
> panel, it's reflected as a variant in the locale identifier string.? For 
> example, "en_US at currency=RUB" for U.S. English using the Russian rubles 
> currency.
> 
> convertToPOSIXLocale() is not expecting such variants, nor such a long 
> string.? The result is a SEGV from memmove() on line 161.? (Additional 
> details are in the bug report.)
> 
> The fix truncates the string passed to convertToPOSIXLocale() before any 
> '@'-denoted variant tags.
> 
> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
> versions of MacOS always return a region along with the language (line 
> 65), so we don't need to query the locale identifier (line 84) to 
> determine the region (hyphenPos is never NULL on line 82).
> 
> Thanks,
> -Brent

From y.umaoka at gmail.com  Fri Oct 13 17:39:12 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 13 Oct 2017 13:39:12 -0400
Subject: <i18n dev> Scanner and NumberFormatProvider
Message-ID: <FD0B06B2-D240-440C-9F32-6B4E915DB57F@gmail.com>

Hello,

I received a problem report from an ICU4J consumer who uses ICU4J Locale SPI module.
ICU NumberFormatProvider returns a class - com.ibm.icu.impl.jdkadapter.NumberFormatICU which extends java.text.NumberFormat.

The ICU4J locale SPI user found the ICU provider causes an issue when he uses Scanner. I can reproduce the problem on my environment as well. The exception call stack shows -

Exception in thread "main" java.lang.ClassCastException: com.ibm.icu.impl.jdkadapter.NumberFormatICU cannot be cast to java.text.DecimalFormat
	at java.util.Scanner.useLocale(Scanner.java:1186)
	at java.util.Scanner.<init>(Scanner.java:540)
	at java.util.Scanner.<init>(Scanner.java:563)
	at test.ScannerTest.main(ScannerTest.java:11)

Below is the location in Scanner.java 

    public Scanner useLocale(Locale locale) {
        if (locale.equals(this.locale))
            return this;

        this.locale = locale;
        DecimalFormat df =
            (DecimalFormat)NumberFormat.getNumberInstance(locale);
        DecimalFormatSymbols dfs = DecimalFormatSymbols.getInstance(locale);

So the implementation blindly cast NumberFormat instance returned by getNumberIntance(Locale) to DecimalFormat.
I thought I reported this issue before. Are you aware of this issue? Maybe, I forgot to file a bug when I investigated this earlier in this year, because I could not find it in java bug.

-Yoshito

From naoto.sato at oracle.com  Fri Oct 13 17:57:22 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 13 Oct 2017 10:57:22 -0700
Subject: <i18n dev> Scanner and NumberFormatProvider
In-Reply-To: <FD0B06B2-D240-440C-9F32-6B4E915DB57F@gmail.com>
References: <FD0B06B2-D240-440C-9F32-6B4E915DB57F@gmail.com>
Message-ID: <b5917d73-6f4e-8013-826b-ddf0fc7a4533@oracle.com>

Hi Umaoka-san,

Yeah, that looks like a bug to me. Can you please file it, as I wasn't 
aware of it being reported.

Naoto

On 10/13/17 10:39 AM, Yoshito Umaoka wrote:
> Hello,
> 
> I received a problem report from an ICU4J consumer who uses ICU4J Locale SPI module.
> ICU NumberFormatProvider returns a class - com.ibm.icu.impl.jdkadapter.NumberFormatICU which extends java.text.NumberFormat.
> 
> The ICU4J locale SPI user found the ICU provider causes an issue when he uses Scanner. I can reproduce the problem on my environment as well. The exception call stack shows -
> 
> Exception in thread "main" java.lang.ClassCastException: com.ibm.icu.impl.jdkadapter.NumberFormatICU cannot be cast to java.text.DecimalFormat
> 	at java.util.Scanner.useLocale(Scanner.java:1186)
> 	at java.util.Scanner.<init>(Scanner.java:540)
> 	at java.util.Scanner.<init>(Scanner.java:563)
> 	at test.ScannerTest.main(ScannerTest.java:11)
> 
> Below is the location in Scanner.java
> 
>      public Scanner useLocale(Locale locale) {
>          if (locale.equals(this.locale))
>              return this;
> 
>          this.locale = locale;
>          DecimalFormat df =
>              (DecimalFormat)NumberFormat.getNumberInstance(locale);
>          DecimalFormatSymbols dfs = DecimalFormatSymbols.getInstance(locale);
> 
> So the implementation blindly cast NumberFormat instance returned by getNumberIntance(Locale) to DecimalFormat.
> I thought I reported this issue before. Are you aware of this issue? Maybe, I forgot to file a bug when I investigated this earlier in this year, because I could not find it in java bug.
> 
> -Yoshito
> 

From y.umaoka at gmail.com  Fri Oct 13 19:55:02 2017
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Fri, 13 Oct 2017 15:55:02 -0400
Subject: <i18n dev> Scanner and NumberFormatProvider
In-Reply-To: <b5917d73-6f4e-8013-826b-ddf0fc7a4533@oracle.com>
References: <FD0B06B2-D240-440C-9F32-6B4E915DB57F@gmail.com>
 <b5917d73-6f4e-8013-826b-ddf0fc7a4533@oracle.com>
Message-ID: <4d1bf2b3-d525-28e2-a045-8453b6650094@gmail.com>

Hi Sato-san,

I filed a bug ID: 9051183.

Thanks,

Yoshito


On 10/13/2017 1:57 PM, Naoto Sato wrote:
> Hi Umaoka-san,
>
> Yeah, that looks like a bug to me. Can you please file it, as I wasn't 
> aware of it being reported.
>
> Naoto
>
> On 10/13/17 10:39 AM, Yoshito Umaoka wrote:
>> Hello,
>>
>> I received a problem report from an ICU4J consumer who uses ICU4J 
>> Locale SPI module.
>> ICU NumberFormatProvider returns a class - 
>> com.ibm.icu.impl.jdkadapter.NumberFormatICU which extends 
>> java.text.NumberFormat.
>>
>> The ICU4J locale SPI user found the ICU provider causes an issue when 
>> he uses Scanner. I can reproduce the problem on my environment as 
>> well. The exception call stack shows -
>>
>> Exception in thread "main" java.lang.ClassCastException: 
>> com.ibm.icu.impl.jdkadapter.NumberFormatICU cannot be cast to 
>> java.text.DecimalFormat
>> ????at java.util.Scanner.useLocale(Scanner.java:1186)
>> ????at java.util.Scanner.<init>(Scanner.java:540)
>> ????at java.util.Scanner.<init>(Scanner.java:563)
>> ????at test.ScannerTest.main(ScannerTest.java:11)
>>
>> Below is the location in Scanner.java
>>
>> ???? public Scanner useLocale(Locale locale) {
>> ???????? if (locale.equals(this.locale))
>> ???????????? return this;
>>
>> ???????? this.locale = locale;
>> ???????? DecimalFormat df =
>> (DecimalFormat)NumberFormat.getNumberInstance(locale);
>> ???????? DecimalFormatSymbols dfs = 
>> DecimalFormatSymbols.getInstance(locale);
>>
>> So the implementation blindly cast NumberFormat instance returned by 
>> getNumberIntance(Locale) to DecimalFormat.
>> I thought I reported this issue before. Are you aware of this issue? 
>> Maybe, I forgot to file a bug when I investigated this earlier in 
>> this year, because I could not find it in java bug.
>>
>> -Yoshito
>>


From brent.christian at oracle.com  Mon Oct 16 18:23:22 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 16 Oct 2017 11:23:22 -0700
Subject: <i18n dev> RFR 8187772 : JVM crash when currency set on MacOS
 10.10 and earlier
In-Reply-To: <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
 <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>
Message-ID: <c9bad825-cb9d-c905-043e-dbb27f127efa@oracle.com>

Thanks, Naoto.  An automated test run looked fine, so I've pushed this 
change.

-Brent

On 10/12/17 12:38 PM, Naoto Sato wrote:
> Looks fine, Brent.
> 
> Naoto
> 
> On 10/12/17 11:52 AM, Brent Christian wrote:
>> Hi,
>>
>> Please review my change to prevent a startup crash on earlier versions 
>> of MacOS.
>>
>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
>> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
>>
>> When a non-default currency is set in the Language & Region control 
>> panel, it's reflected as a variant in the locale identifier string.  
>> For example, "en_US at currency=RUB" for U.S. English using the Russian 
>> rubles currency.
>>
>> convertToPOSIXLocale() is not expecting such variants, nor such a long 
>> string.? The result is a SEGV from memmove() on line 161.? (Additional 
>> details are in the bug report.)
>>
>> The fix truncates the string passed to convertToPOSIXLocale() before 
>> any '@'-denoted variant tags.
>>
>> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
>> versions of MacOS always return a region along with the language (line 
>> 65), so we don't need to query the locale identifier (line 84) to 
>> determine the region (hyphenPos is never NULL on line 82).
>>
>> Thanks,
>> -Brent

From clement at guillaume.bzh  Thu Oct 19 18:57:12 2017
From: clement at guillaume.bzh (=?UTF-8?Q?Cl=C3=A9ment_Guillaume?=)
Date: Thu, 19 Oct 2017 11:57:12 -0700
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
Message-ID: <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>

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>:

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

From naoto.sato at oracle.com  Fri Oct 20 21:20:57 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Oct 2017 14:20:57 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
Message-ID: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>

Hello,

Please review the changes for the following two issues:

8189272: CLDR and JRE LocaleProviderAdapters silently swallow exceptions [1]
8189291: Test policy should extend the default system policy [2]

The proposed fixes for the above issues are located below, respectively:

http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
http://cr.openjdk.java.net/~naoto/8189291/webrev.00/

The fix to 8189272 will throw exceptions that were swallowed in those 
providers, which should not happen in proper environment. That fix makes 
test cases with security manager fail. The fix to 8189291 addresses it.

Naoto

[1] https://bugs.openjdk.java.net/browse/JDK-8189272
[2] https://bugs.openjdk.java.net/browse/JDK-8189291

From mandy.chung at oracle.com  Fri Oct 20 21:45:38 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 20 Oct 2017 14:45:38 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
In-Reply-To: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
Message-ID: <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>



On 10/20/17 2:20 PM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following two issues:
>
> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
> exceptions [1]
> 8189291: Test policy should extend the default system policy [2]
>
> The proposed fixes for the above issues are located below, respectively:
>
> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/

Looks fine.? The installed providers are our implementation and silently 
ignore any exception would make it really hard to diagnose problems.?? 
This change will help the diagnosability.

> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>

If the default policy is not cached early before any test policy is 
constructed, the test might get the wrong Policy object set by the test 
previously (for example, if it runs in agentvm mode).?? It would be more 
reliable if this is cached as the static field in the test class (i.e. 
the enclosing class of the policy subclass) - like CallerSensitiveTest.

test/jdk/sun/util/locale/provider/Bug8038436.java
- I think the test fix should be part of JDK-8189272, right?

Mandy
> The fix to 8189272 will throw exceptions that were swallowed in those 
> providers, which should not happen in proper environment. That fix 
> makes test cases with security manager fail. The fix to 8189291 
> addresses it.
>
> Naoto
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
> [2] https://bugs.openjdk.java.net/browse/JDK-8189291


From naoto.sato at oracle.com  Sat Oct 21 00:05:17 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Oct 2017 17:05:17 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
In-Reply-To: <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
Message-ID: <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>

Hi Mandy,

Thanks for the review. Webrevs updated as suggested:

http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
http://cr.openjdk.java.net/~naoto/8189291/webrev.01/

Naoto

On 10/20/17 2:45 PM, mandy chung wrote:
> 
> 
> On 10/20/17 2:20 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following two issues:
>>
>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>> exceptions [1]
>> 8189291: Test policy should extend the default system policy [2]
>>
>> The proposed fixes for the above issues are located below, respectively:
>>
>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
> 
> Looks fine.? The installed providers are our implementation and silently 
> ignore any exception would make it really hard to diagnose problems. 
> This change will help the diagnosability.
> 
>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>
> 
> If the default policy is not cached early before any test policy is 
> constructed, the test might get the wrong Policy object set by the test 
> previously (for example, if it runs in agentvm mode).?? It would be more 
> reliable if this is cached as the static field in the test class (i.e. 
> the enclosing class of the policy subclass) - like CallerSensitiveTest.
> 
> test/jdk/sun/util/locale/provider/Bug8038436.java
> - I think the test fix should be part of JDK-8189272, right?
> 
> Mandy
>> The fix to 8189272 will throw exceptions that were swallowed in those 
>> providers, which should not happen in proper environment. That fix 
>> makes test cases with security manager fail. The fix to 8189291 
>> addresses it.
>>
>> Naoto
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
> 

From naoto.sato at oracle.com  Mon Oct 23 17:56:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Oct 2017 10:56:07 -0700
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
 <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
Message-ID: <20a9edcc-11db-0111-cbab-f384b1ce98d4@oracle.com>

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

From martinrb at google.com  Mon Oct 23 20:34:51 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Oct 2017 13:34:51 -0700
Subject: <i18n dev> tzdata2017c is out
Message-ID: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>

tzdata2017c came out today, and the elves at Google are working hard to
incorporate changes in hours or days instead of weeks or quarters.  One
thing we noticed is that one of the java.time tck tests was broken by
tzdata rewrite of history.  Here's the fix we're applying (s/1879/1892/g):

@@ -941,21 +941,21 @@
     }

     public void
test_Apia_jumpForwardOverInternationalDateLine_P12_to_M12() {
-        // transition occurred at 1879-07-04T00:00+12:33:04
+        // transition occurred at 1892-07-04T00:00+12:33:04
         ZoneRules test = pacificApia();
-        Instant instantBefore = LocalDate.of(1879, 7,
2).atStartOfDay(ZoneOffset.UTC).toInstant();
+        Instant instantBefore = LocalDate.of(1892, 7,
2).atStartOfDay(ZoneOffset.UTC).toInstant();
         ZoneOffsetTransition trans = test.nextTransition(instantBefore);
-        assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1879, 7,
5, 0, 0));
-        assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1879, 7,
4, 0, 0));
+        assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1892, 7,
5, 0, 0));
+        assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1892, 7,
4, 0, 0));
         assertEquals(trans.isGap(), false);
         assertEquals(trans.isOverlap(), true);

 assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(+12, 33,
4)), true);

 assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(-11,
-26, -56)), true);
         assertEquals(trans.getDuration(), Duration.ofHours(-24));
-        assertEquals(trans.getInstant(), LocalDateTime.of(1879, 7, 4, 0,
0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));
+        assertEquals(trans.getInstant(), LocalDateTime.of(1892, 7, 4, 0,
0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

-        ZonedDateTime zdt = ZonedDateTime.of(1879, 7, 4, 23, 0, 0, 0,
ZoneId.of("Pacific/Apia"));
-        assertEquals(zdt.plusHours(2).toLocalDateTime(),
LocalDateTime.of(1879, 7, 4, 1, 0, 0));
+        ZonedDateTime zdt = ZonedDateTime.of(1892, 7, 4, 23, 0, 0, 0,
ZoneId.of("Pacific/Apia"));
+        assertEquals(zdt.plusHours(2).toLocalDateTime(),
LocalDateTime.of(1892, 7, 4, 1, 0, 0));
     }


 //-------------------------------------------------------------------------

From mark.reinhold at oracle.com  Mon Oct 23 23:08:55 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 23 Oct 2017 16:08:55 -0700 (PDT)
Subject: <i18n dev> JEP 314: Additional Unicode Language-Tag Extensions
Message-ID: <20171023230855.599E5EB365@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/314

- Mark

From mandy.chung at oracle.com  Tue Oct 24 00:48:02 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 23 Oct 2017 17:48:02 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
In-Reply-To: <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
Message-ID: <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>



On 10/20/17 5:05 PM, Naoto Sato wrote:
> Hi Mandy,
>
> Thanks for the review. Webrevs updated as suggested:
>
> http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
> http://cr.openjdk.java.net/~naoto/8189291/webrev.01/
>

DEFAULT_POLICY in test/jdk/java/util/logging/* tests can be moved to the 
enclosing class as suggested.

Other than that, the change looks good.

Mandy

> Naoto
>
> On 10/20/17 2:45 PM, mandy chung wrote:
>>
>>
>> On 10/20/17 2:20 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the following two issues:
>>>
>>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>>> exceptions [1]
>>> 8189291: Test policy should extend the default system policy [2]
>>>
>>> The proposed fixes for the above issues are located below, 
>>> respectively:
>>>
>>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
>>
>> Looks fine.? The installed providers are our implementation and 
>> silently ignore any exception would make it really hard to diagnose 
>> problems. This change will help the diagnosability.
>>
>>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>>
>>
>> If the default policy is not cached early before any test policy is 
>> constructed, the test might get the wrong Policy object set by the 
>> test previously (for example, if it runs in agentvm mode).?? It would 
>> be more reliable if this is cached as the static field in the test 
>> class (i.e. the enclosing class of the policy subclass) - like 
>> CallerSensitiveTest.
>>
>> test/jdk/sun/util/locale/provider/Bug8038436.java
>> - I think the test fix should be part of JDK-8189272, right?
>>
>> Mandy
>>> The fix to 8189272 will throw exceptions that were swallowed in 
>>> those providers, which should not happen in proper environment. That 
>>> fix makes test cases with security manager fail. The fix to 8189291 
>>> addresses it.
>>>
>>> Naoto
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
>>


From naoto.sato at oracle.com  Tue Oct 24 15:00:40 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 24 Oct 2017 08:00:40 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
In-Reply-To: <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
 <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
Message-ID: <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>

Hi Mandy,

Sorry, I seem to have generated/uploaded an incorrect webrev for 
8189291. Here is the correct one:

http://cr.openjdk.java.net/~naoto/8189291/webrev.02/

Naoto

On 10/23/17 5:48 PM, mandy chung wrote:
> 
> 
> On 10/20/17 5:05 PM, Naoto Sato wrote:
>> Hi Mandy,
>>
>> Thanks for the review. Webrevs updated as suggested:
>>
>> http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
>> http://cr.openjdk.java.net/~naoto/8189291/webrev.01/
>>
> 
> DEFAULT_POLICY in test/jdk/java/util/logging/* tests can be moved to the 
> enclosing class as suggested.
> 
> Other than that, the change looks good.
> 
> Mandy
> 
>> Naoto
>>
>> On 10/20/17 2:45 PM, mandy chung wrote:
>>>
>>>
>>> On 10/20/17 2:20 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for the following two issues:
>>>>
>>>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>>>> exceptions [1]
>>>> 8189291: Test policy should extend the default system policy [2]
>>>>
>>>> The proposed fixes for the above issues are located below, 
>>>> respectively:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
>>>
>>> Looks fine.? The installed providers are our implementation and 
>>> silently ignore any exception would make it really hard to diagnose 
>>> problems. This change will help the diagnosability.
>>>
>>>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>>>
>>>
>>> If the default policy is not cached early before any test policy is 
>>> constructed, the test might get the wrong Policy object set by the 
>>> test previously (for example, if it runs in agentvm mode).?? It would 
>>> be more reliable if this is cached as the static field in the test 
>>> class (i.e. the enclosing class of the policy subclass) - like 
>>> CallerSensitiveTest.
>>>
>>> test/jdk/sun/util/locale/provider/Bug8038436.java
>>> - I think the test fix should be part of JDK-8189272, right?
>>>
>>> Mandy
>>>> The fix to 8189272 will throw exceptions that were swallowed in 
>>>> those providers, which should not happen in proper environment. That 
>>>> fix makes test cases with security manager fail. The fix to 8189291 
>>>> addresses it.
>>>>
>>>> Naoto
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
>>>
> 

From mandy.chung at oracle.com  Tue Oct 24 15:41:42 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 24 Oct 2017 08:41:42 -0700
Subject: <i18n dev> [10] RFR: 8189272 & 8189291
In-Reply-To: <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
 <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
 <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>
Message-ID: <f5d1bbc8-1507-7f86-8839-90d675e23d6f@oracle.com>



On 10/24/17 8:00 AM, Naoto Sato wrote:
> Hi Mandy,
>
> Sorry, I seem to have generated/uploaded an incorrect webrev for 
> 8189291. Here is the correct one:
>
> http://cr.openjdk.java.net/~naoto/8189291/webrev.02/
>

+1

Mandy


From rachna.goel at oracle.com  Fri Oct 27 06:24:54 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 27 Oct 2017 11:54:54 +0530
Subject: <i18n dev> JDK10 RFR of JDK-8185841:Values from getFirstDayOfWeek()
 are inconsistent with CLDR
Message-ID: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>

Hi,

Kindly review the fix to JDK-8185841.

Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.

patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/

Fix is to relocate this region dependent data. New Bundle will be 
generated when Locale id has non empty script and country code and it 
contains region dependent data.
  e.g for "az_Latn_AZ" locale, CalendarData_az_AZ.java Bundle will be 
generated and the data currently in CalendarData_az_Latn_AZ.java should 
be relocated into it.

-- 
Thanks,
Rachna


From ramanand.patil at oracle.com  Fri Oct 27 07:08:28 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 27 Oct 2017 00:08:28 -0700 (PDT)
Subject: <i18n dev> tzdata2017c is out
In-Reply-To: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>
References: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>
Message-ID: <a26ceaed-6f7f-4787-8d5d-79914dc4e9ad@default>

Hi Martin,

Thank you very much for the heads-up. I have filed a bug for the same: https://bugs.openjdk.java.net/browse/JDK-8190259

Thank you for the patch as well. This will be integrated into JDK along with the tzdata2017c.

?

Regards,

Ramanand.

?

From: Martin Buchholz [mailto:martinrb at google.com] 
Sent: Tuesday, October 24, 2017 2:05 AM
To: i18n-dev at openjdk.java.net; core-libs-dev <core-libs-dev at openjdk.java.net>; Ramanand Patil <ramanand.patil at oracle.com>; Stephen Colebourne <scolebourne at joda.org>
Subject: tzdata2017c is out

?

tzdata2017c came out today, and the elves at Google are working hard to incorporate changes in hours or days instead of weeks or quarters.? One thing we noticed is that one of the java.time tck tests was broken by tzdata rewrite of history.? Here's the fix we're applying (s/1879/1892/g):

?

@@ -941,21 +941,21 @@

? ? ?}

?

? ? ?public void test_Apia_jumpForwardOverInternationalDateLine_P12_to_M12() {

-? ? ? ? // transition occurred at 1879-07-04T00:00+12:33:04

+? ? ? ? // transition occurred at 1892-07-04T00:00+12:33:04

? ? ? ? ?ZoneRules test = pacificApia();

-? ? ? ? Instant instantBefore = LocalDate.of(1879, 7, 2).atStartOfDay(ZoneOffset.UTC).toInstant();

+? ? ? ? Instant instantBefore = LocalDate.of(1892, 7, 2).atStartOfDay(ZoneOffset.UTC).toInstant();

? ? ? ? ?ZoneOffsetTransition trans = test.nextTransition(instantBefore);

-? ? ? ? assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1879, 7, 5, 0, 0));

-? ? ? ? assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1879, 7, 4, 0, 0));

+? ? ? ? assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1892, 7, 5, 0, 0));

+? ? ? ? assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1892, 7, 4, 0, 0));

? ? ? ? ?assertEquals(trans.isGap(), false);

? ? ? ? ?assertEquals(trans.isOverlap(), true);

? ? ? ? ?assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(+12, 33, 4)), true);

? ? ? ? ?assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)), true);

? ? ? ? ?assertEquals(trans.getDuration(), Duration.ofHours(-24));

-? ? ? ? assertEquals(trans.getInstant(), LocalDateTime.of(1879, 7, 4, 0, 0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

+? ? ? ? assertEquals(trans.getInstant(), LocalDateTime.of(1892, 7, 4, 0, 0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

?

-? ? ? ? ZonedDateTime zdt = ZonedDateTime.of(1879, 7, 4, 23, 0, 0, 0, ZoneId.of("Pacific/Apia"));

-? ? ? ? assertEquals(zdt.plusHours(2).toLocalDateTime(), LocalDateTime.of(1879, 7, 4, 1, 0, 0));

+? ? ? ? ZonedDateTime zdt = ZonedDateTime.of(1892, 7, 4, 23, 0, 0, 0, ZoneId.of("Pacific/Apia"));

+? ? ? ? assertEquals(zdt.plusHours(2).toLocalDateTime(), LocalDateTime.of(1892, 7, 4, 1, 0, 0));

? ? ?}

?

? ? ?//-------------------------------------------------------------------------

?

From naoto.sato at oracle.com  Fri Oct 27 23:26:05 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Oct 2017 16:26:05 -0700
Subject: <i18n dev> JDK10 RFR of JDK-8185841:Values from
 getFirstDayOfWeek() are inconsistent with CLDR
In-Reply-To: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>
References: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>
Message-ID: <22d6d459-a209-89c5-263a-2a82218a71a7@oracle.com>

Looks fine.

Naoto

On 10/26/17 11:24 PM, Rachna Goel wrote:
> Hi,
> 
> Kindly review the fix to JDK-8185841.
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.
> 
> patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/
> 
> Fix is to relocate this region dependent data. New Bundle will be 
> generated when Locale id has non empty script and country code and it 
> contains region dependent data.
>  ?e.g for "az_Latn_AZ" locale, CalendarData_az_AZ.java Bundle will be 
> generated and the data currently in CalendarData_az_Latn_AZ.java should 
> be relocated into it.
> 

From rachna.goel at oracle.com  Tue Oct 31 11:56:45 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 31 Oct 2017 17:26:45 +0530
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <20a9edcc-11db-0111-cbab-f384b1ce98d4@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
 <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
 <20a9edcc-11db-0111-cbab-f384b1ce98d4@oracle.com>
Message-ID: <9d4d3840-d4c3-c066-8288-ddac6cdcc862@oracle.com>

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


From rachna.goel at oracle.com  Tue Oct 31 12:04:47 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 31 Oct 2017 17:34:47 +0530
Subject: <i18n dev> java 9 AKST timezone parsing
In-Reply-To: <9d4d3840-d4c3-c066-8288-ddac6cdcc862@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
 <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
 <20a9edcc-11db-0111-cbab-f384b1ce98d4@oracle.com>
 <9d4d3840-d4c3-c066-8288-ddac6cdcc862@oracle.com>
Message-ID: <2baf7d2e-2796-aa93-aa79-bd342e150ac9@oracle.com>

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