From aleksej.efimov at oracle.com  Tue Feb  3 15:59:33 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 03 Feb 2015 18:59:33 +0300
Subject: <i18n dev> [9] RFR: 8072042: (tz) Support tzdata2015a
Message-ID: <54D0F065.9010304@oracle.com>

Hi,

Could I have a review the latest tzdata2015a integration fix to JDK9, 
please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.

Thank you,
Aleksej

Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
Webrev with changes: http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
Regression tests executed: test/sun/util/calendar\ 
test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter

From sean.coffey at oracle.com  Tue Feb  3 17:06:49 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 03 Feb 2015 17:06:49 +0000
Subject: <i18n dev> [9] RFR: 8072042: (tz) Support tzdata2015a
In-Reply-To: <54D0F065.9010304@oracle.com>
References: <54D0F065.9010304@oracle.com>
Message-ID: <54D10029.909@oracle.com>

Looks good to me.

regards,
Sean.

On 03/02/2015 15:59, Aleksej Efimov wrote:
> Hi,
>
> Could I have a review the latest tzdata2015a integration fix to JDK9, 
> please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
> jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
>
> Thank you,
> Aleksej
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
> Webrev with changes: 
> http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
> Regression tests executed: test/sun/util/calendar\ 
> test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
> test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter


From masayoshi.okutsu at oracle.com  Thu Feb  5 02:50:57 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 05 Feb 2015 11:50:57 +0900
Subject: <i18n dev> [9] RFR: 8072042: (tz) Support tzdata2015a
In-Reply-To: <54D0F065.9010304@oracle.com>
References: <54D0F065.9010304@oracle.com>
Message-ID: <54D2DA91.4010708@oracle.com>

Looks good to me.

Masayoshi

On 2/4/2015 12:59 AM, Aleksej Efimov wrote:
> Hi,
>
> Could I have a review the latest tzdata2015a integration fix to JDK9, 
> please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
> jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
>
> Thank you,
> Aleksej
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
> Webrev with changes: 
> http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
> Regression tests executed: test/sun/util/calendar\ 
> test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
> test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter


From sean.coffey at oracle.com  Fri Feb  6 17:51:38 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Fri, 06 Feb 2015 17:51:38 +0000
Subject: <i18n dev> RFR : 8071447: IBM1166 Locale Request for Kazakh
	characters
Message-ID: <54D4FF2A.3010903@oracle.com>

Looking for a code review around the addition of this new charset. I 
haven't added a charset before so I'm hoping I caught all the necessary 
steps and edits.

Sherman, would appreciate if you could cast a careful eye over this one.

In particular, I'm wondering if I need to take extra steps due to this 
comment in the extsbcs file :
# map tables for 1140-1149 are updated manualy with the u+20ac entry

(Is 1166 impacted? what's the reason for such a comment?)

Also - I didn't create an .nr file for IBM1166 in 
make/data/charsetmapping/ - Let me know if it's needed.

bug report : https://bugs.openjdk.java.net/browse/JDK-8071447
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447/webrev/

regards,
Sean.



From sean.coffey at oracle.com  Wed Feb 11 18:36:58 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 11 Feb 2015 18:36:58 +0000
Subject: <i18n dev> RFR : 8071447: IBM1166 Locale Request for Kazakh
	characters
In-Reply-To: <54D4FF2A.3010903@oracle.com>
References: <54D4FF2A.3010903@oracle.com>
Message-ID: <54DBA14A.8030906@oracle.com>

Just a reminder on this one..

regards,
Sean.

On 06/02/15 17:51, Se?n Coffey wrote:
> Looking for a code review around the addition of this new charset. I 
> haven't added a charset before so I'm hoping I caught all the 
> necessary steps and edits.
>
> Sherman, would appreciate if you could cast a careful eye over this one.
>
> In particular, I'm wondering if I need to take extra steps due to this 
> comment in the extsbcs file :
> # map tables for 1140-1149 are updated manualy with the u+20ac entry
>
> (Is 1166 impacted? what's the reason for such a comment?)
>
> Also - I didn't create an .nr file for IBM1166 in 
> make/data/charsetmapping/ - Let me know if it's needed.
>
> bug report : https://bugs.openjdk.java.net/browse/JDK-8071447
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447/webrev/
>
> regards,
> Sean.
>
>


From masayoshi.okutsu at oracle.com  Wed Feb 18 08:54:26 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 18 Feb 2015 17:54:26 +0900
Subject: <i18n dev> [9] RFR: 8072602: Unpredictable timezone on Windows when
 OS's timezone is not found in tzmappings
Message-ID: <54E45342.5090509@oracle.com>

Hi,

Could you please review the fix for 8072602? On Windows, the time zone 
detection code always used "GMT" if the Windows time zone can't be 
mapped to an Olson time zone ID. This fix is to use a custom time zone 
ID based on the GMT offset so that Java produces the same local time as 
the platform. A regression test requires to modify tzmappings. So this 
one is noreg-hard.

But report:
https://bugs.openjdk.java.net/browse/JDK-8072602
Webrev:
http://cr.openjdk.java.net/~okutsu/9/8072602/webrev.00/

Thanks,
Masayoshi


From sean.coffey at oracle.com  Tue Feb 24 14:02:06 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 24 Feb 2015 14:02:06 +0000
Subject: <i18n dev> RFR : 8071447: IBM1166 Locale Request for Kazakh
	characters
In-Reply-To: <54D4FF2A.3010903@oracle.com>
References: <54D4FF2A.3010903@oracle.com>
Message-ID: <54EC845E.70300@oracle.com>

I've updated the JDK 9 changes to take account of the recent NIO charset 
work that Sherman undertook for modules.

new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447.v2/webrev/

I'm also pasting the map file differences here between the 1025 and 1166 
IBM charsets for easier comparison [1].

regards,
Sean.

[1]
$diff IBM1025.map IBM1166.map
1d0
< #Generated from IBM1025.java
23c22
< 0x15  U+000a
---
 > 0x15  U+0085
68,69c67,68
< 0x42  U+0452
< 0x43  U+0453
---
 > 0x42  U+04d9
 > 0x43  U+0493
74c73
< 0x48  U+0457
---
 > 0x48  U+049b
83,86c82,85
< 0x51  U+0459
< 0x52  U+045a
< 0x53  U+045b
< 0x54  U+045c
---
 > 0x51  U+04a3
 > 0x52  U+04e9
 > 0x53  U+04b1
 > 0x54  U+04af
88c87
< 0x56  U+045f
---
 > 0x56  U+04bb
91c90
< 0x59  U+0402
---
 > 0x59  U+04d8
100c99
< 0x62  U+0403
---
 > 0x62  U+0492
105c104
< 0x67  U+0407
---
 > 0x67  U+049a
107c106
< 0x69  U+0409
---
 > 0x69  U+04a2
114,116c113,115
< 0x70  U+040a
< 0x71  U+040b
< 0x72  U+040c
---
 > 0x70  U+04e8
 > 0x71  U+04b0
 > 0x72  U+04ae
119c118
< 0x75  U+040f
---
 > 0x75  U+04ba
227c226
< 0xe1  U+00a7
---
 > 0xe1  U+20ac
$

On 06/02/2015 17:51, Se?n Coffey wrote:
> Looking for a code review around the addition of this new charset. I 
> haven't added a charset before so I'm hoping I caught all the 
> necessary steps and edits.
>
> Sherman, would appreciate if you could cast a careful eye over this one.
>
> In particular, I'm wondering if I need to take extra steps due to this 
> comment in the extsbcs file :
> # map tables for 1140-1149 are updated manualy with the u+20ac entry
>
> (Is 1166 impacted? what's the reason for such a comment?)
>
> Also - I didn't create an .nr file for IBM1166 in 
> make/data/charsetmapping/ - Let me know if it's needed.
>
> bug report : https://bugs.openjdk.java.net/browse/JDK-8071447
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447/webrev/
>
> regards,
> Sean.
>
>


From xueming.shen at oracle.com  Wed Feb 25 05:31:44 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 24 Feb 2015 21:31:44 -0800
Subject: <i18n dev> RFR : 8071447: IBM1166 Locale Request for Kazakh
	characters
In-Reply-To: <54EC845E.70300@oracle.com>
References: <54D4FF2A.3010903@oracle.com> <54EC845E.70300@oracle.com>
Message-ID: <54ED5E40.9000404@oracle.com>

Sean,

Based on https://bugs.openjdk.java.net/browse/JDK-4159519, 
"historically" our ebcdic charsets
alway do

IBMxxxx.map:

0x15    U+000a
0x25    U+000a

IBMxxx.c2b
0x15    U+0085

IBMxxx.nr
0x25    U+000a

Someone had complained that "this is not correct". But it has been this 
way for a long time.

The rest looks fine.

I might have overlooked the implementation for the early update releases?

-Sherman


On 2/24/15 6:02 AM, Se?n Coffey wrote:
> I've updated the JDK 9 changes to take account of the recent NIO 
> charset work that Sherman undertook for modules.
>
> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447.v2/webrev/
>
> I'm also pasting the map file differences here between the 1025 and 
> 1166 IBM charsets for easier comparison [1].
>
> regards,
> Sean.
>
> [1]
> $diff IBM1025.map IBM1166.map
> 1d0
> < #Generated from IBM1025.java
> 23c22
> < 0x15  U+000a
> ---
> > 0x15  U+0085
> 68,69c67,68
> < 0x42  U+0452
> < 0x43  U+0453
> ---
> > 0x42  U+04d9
> > 0x43  U+0493
> 74c73
> < 0x48  U+0457
> ---
> > 0x48  U+049b
> 83,86c82,85
> < 0x51  U+0459
> < 0x52  U+045a
> < 0x53  U+045b
> < 0x54  U+045c
> ---
> > 0x51  U+04a3
> > 0x52  U+04e9
> > 0x53  U+04b1
> > 0x54  U+04af
> 88c87
> < 0x56  U+045f
> ---
> > 0x56  U+04bb
> 91c90
> < 0x59  U+0402
> ---
> > 0x59  U+04d8
> 100c99
> < 0x62  U+0403
> ---
> > 0x62  U+0492
> 105c104
> < 0x67  U+0407
> ---
> > 0x67  U+049a
> 107c106
> < 0x69  U+0409
> ---
> > 0x69  U+04a2
> 114,116c113,115
> < 0x70  U+040a
> < 0x71  U+040b
> < 0x72  U+040c
> ---
> > 0x70  U+04e8
> > 0x71  U+04b0
> > 0x72  U+04ae
> 119c118
> < 0x75  U+040f
> ---
> > 0x75  U+04ba
> 227c226
> < 0xe1  U+00a7
> ---
> > 0xe1  U+20ac
> $
>
> On 06/02/2015 17:51, Se?n Coffey wrote:
>> Looking for a code review around the addition of this new charset. I 
>> haven't added a charset before so I'm hoping I caught all the 
>> necessary steps and edits.
>>
>> Sherman, would appreciate if you could cast a careful eye over this one.
>>
>> In particular, I'm wondering if I need to take extra steps due to 
>> this comment in the extsbcs file :
>> # map tables for 1140-1149 are updated manualy with the u+20ac entry
>>
>> (Is 1166 impacted? what's the reason for such a comment?)
>>
>> Also - I didn't create an .nr file for IBM1166 in 
>> make/data/charsetmapping/ - Let me know if it's needed.
>>
>> bug report : https://bugs.openjdk.java.net/browse/JDK-8071447
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447/webrev/
>>
>> regards,
>> Sean.
>>
>>
>


From yuka.kamiya at oracle.com  Wed Feb 25 07:50:21 2015
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 25 Feb 2015 16:50:21 +0900
Subject: <i18n dev> [9] RFR: 8072602: Unpredictable timezone on Windows
 when OS's timezone is not found in tzmappings
In-Reply-To: <54E45342.5090509@oracle.com>
References: <54E45342.5090509@oracle.com>
Message-ID: <54ED7EBD.9070501@oracle.com>

Hi,

The fix looks ok to me.

Thanks,
--
Yuka


On 2015/02/18 17:54, Masayoshi Okutsu wrote:
> Hi,
>
> Could you please review the fix for 8072602? On Windows, the time zone 
> detection code always used "GMT" if the Windows time zone can't be 
> mapped to an Olson time zone ID. This fix is to use a custom time zone 
> ID based on the GMT offset so that Java produces the same local time 
> as the platform. A regression test requires to modify tzmappings. So 
> this one is noreg-hard.
>
> But report:
> https://bugs.openjdk.java.net/browse/JDK-8072602
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8072602/webrev.00/
>
> Thanks,
> Masayoshi
>


From sean.coffey at oracle.com  Wed Feb 25 11:57:40 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 25 Feb 2015 11:57:40 +0000
Subject: <i18n dev> RFR : 8071447: IBM1166 Locale Request for Kazakh
	characters
In-Reply-To: <54ED5E40.9000404@oracle.com>
References: <54D4FF2A.3010903@oracle.com> <54EC845E.70300@oracle.com>
	<54ED5E40.9000404@oracle.com>
Message-ID: <54EDB8B4.4040308@oracle.com>

Thanks for the review Sherman. I've modified the map file and added an 
IBM1166.nr file as per your advice.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447.v3/webrev/

I'll handle the edits for 8u and 7u also. (which I plan to backport to)

regards,
Sean.

On 25/02/15 05:31, Xueming Shen wrote:
> Sean,
>
> Based on https://bugs.openjdk.java.net/browse/JDK-4159519, 
> "historically" our ebcdic charsets
> alway do
>
> IBMxxxx.map:
>
> 0x15    U+000a
> 0x25    U+000a
>
> IBMxxx.c2b
> 0x15    U+0085
>
> IBMxxx.nr
> 0x25    U+000a
>
> Someone had complained that "this is not correct". But it has been 
> this way for a long time.
>
> The rest looks fine.
>
> I might have overlooked the implementation for the early update releases?
>
> -Sherman
>
>
> On 2/24/15 6:02 AM, Se?n Coffey wrote:
>> I've updated the JDK 9 changes to take account of the recent NIO 
>> charset work that Sherman undertook for modules.
>>
>> new webrev : 
>> http://cr.openjdk.java.net/~coffeys/webrev.8071447.v2/webrev/
>>
>> I'm also pasting the map file differences here between the 1025 and 
>> 1166 IBM charsets for easier comparison [1].
>>
>> regards,
>> Sean.
>>
>> [1]
>> $diff IBM1025.map IBM1166.map
>> 1d0
>> < #Generated from IBM1025.java
>> 23c22
>> < 0x15  U+000a
>> ---
>> > 0x15  U+0085
>> 68,69c67,68
>> < 0x42  U+0452
>> < 0x43  U+0453
>> ---
>> > 0x42  U+04d9
>> > 0x43  U+0493
>> 74c73
>> < 0x48  U+0457
>> ---
>> > 0x48  U+049b
>> 83,86c82,85
>> < 0x51  U+0459
>> < 0x52  U+045a
>> < 0x53  U+045b
>> < 0x54  U+045c
>> ---
>> > 0x51  U+04a3
>> > 0x52  U+04e9
>> > 0x53  U+04b1
>> > 0x54  U+04af
>> 88c87
>> < 0x56  U+045f
>> ---
>> > 0x56  U+04bb
>> 91c90
>> < 0x59  U+0402
>> ---
>> > 0x59  U+04d8
>> 100c99
>> < 0x62  U+0403
>> ---
>> > 0x62  U+0492
>> 105c104
>> < 0x67  U+0407
>> ---
>> > 0x67  U+049a
>> 107c106
>> < 0x69  U+0409
>> ---
>> > 0x69  U+04a2
>> 114,116c113,115
>> < 0x70  U+040a
>> < 0x71  U+040b
>> < 0x72  U+040c
>> ---
>> > 0x70  U+04e8
>> > 0x71  U+04b0
>> > 0x72  U+04ae
>> 119c118
>> < 0x75  U+040f
>> ---
>> > 0x75  U+04ba
>> 227c226
>> < 0xe1  U+00a7
>> ---
>> > 0xe1  U+20ac
>> $
>>
>> On 06/02/2015 17:51, Se?n Coffey wrote:
>>> Looking for a code review around the addition of this new charset. I 
>>> haven't added a charset before so I'm hoping I caught all the 
>>> necessary steps and edits.
>>>
>>> Sherman, would appreciate if you could cast a careful eye over this one.
>>>
>>> In particular, I'm wondering if I need to take extra steps due to 
>>> this comment in the extsbcs file :
>>> # map tables for 1140-1149 are updated manualy with the u+20ac entry
>>>
>>> (Is 1166 impacted? what's the reason for such a comment?)
>>>
>>> Also - I didn't create an .nr file for IBM1166 in 
>>> make/data/charsetmapping/ - Let me know if it's needed.
>>>
>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8071447
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8071447/webrev/
>>>
>>> regards,
>>> Sean.
>>>
>>>
>>
>