From jjg at openjdk.org  Thu Dec  1 19:36:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:36:16 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>

> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
> 
> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
> 
> "Normalized" means...
> * Use `https:` where possible (includes pretty much all cases)
> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
> * Point to the root page of a multi-page spec
> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
> 
> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
> 
> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
> 
> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
> 
> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
> 
> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
> 
> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Change ietf.org URLs to use rfc-editor.org
 - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
 - Remove updates from unexported files
 - Prefix RFC titles with `RFC NNNN:`
 - JDK-8296547: Add @spec tags to API

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11073/files
  - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02-03

  Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod
  Patch: https://git.openjdk.org/jdk/pull/11073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073

PR: https://git.openjdk.org/jdk/pull/11073

From jjg at openjdk.org  Thu Dec  1 19:40:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:40:16 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
Message-ID: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>

On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Change ietf.org URLs to use rfc-editor.org
>>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>>  - Remove updates from unexported files
>>  - Prefix RFC titles with `RFC NNNN:`
>>  - JDK-8296547: Add @spec tags to API
>
> src/java.base/share/classes/java/lang/Character.java line 172:
> 
>> 170:  * occur. For example, in a future release, synchronization may fail.
>> 171:  *
>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
> 
> This should probably be removed, as the original link (explaining `U+n` notation) is broken.

@naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From jjg at openjdk.org  Thu Dec  1 19:57:33 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 19:57:33 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v3]
In-Reply-To: <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <LHFaSiga6SwAv5hT39-G7w7JE3I7Ufjyn0LJZ_zQ3UU=.dfd156c3-6ca8-4ad8-b582-f0f60e6cd404@github.com>
 <Y0Qj1qIytaKulH9059ekA6usyUpypf7mVymxst4jwDs=.bb77135a-cdf2-4d3e-9801-c417bdf53e37@github.com>
Message-ID: <XVUIV3LMzWV4Y-0veldczkRr4bD_X-2JxbRLJRDikeI=.36f81c4a-f467-4352-90ba-cc3fc656791f@github.com>

On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove updates from unexported files
>
> src/java.xml/share/classes/javax/xml/XMLConstants.java line 35:
> 
>> 33:  * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition)
>> 34:  * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition)
>> 35:  * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition
> 
> Hi Jon,
> 
> I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0.
> points to the fifth edition while @see second.
> 
> A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read.
> 
> [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html

The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work.   The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From naoto at openjdk.org  Thu Dec  1 21:23:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 21:23:09 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com>
 <q9avJLkpJ4wgyuswrLm_YSdqUD_5GNnWYPEux_Xy7OI=.cb1704f2-7452-435e-984e-1aeb917ac907@github.com>
Message-ID: <NzMOOFfncZ1U5XWrfhkWjwcvhKxiand9c5VfptjGehM=.9d78d127-3374-4c48-8a7d-614b64fcdb0a@github.com>

On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 172:
>> 
>>> 170:  * occur. For example, in a future release, synchronization may fail.
>>> 171:  *
>>> 172:  * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0
>> 
>> This should probably be removed, as the original link (explaining `U+n` notation) is broken.
>
> @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards.

Either way is fine with me. I will fix it up if you choose the latter.

-------------

PR: https://git.openjdk.org/jdk/pull/11073

From ysatowse at openjdk.org  Fri Dec  2 01:18:16 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 2 Dec 2022 01:18:16 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

The following files need to be updated with the timezone data version.  
src/java.base/share/data/tzdata/VERSION
test/jdk/java/util/TimeZone/TimeZoneData/VERSION

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From dfuchs at openjdk.org  Fri Dec  2 12:15:23 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 2 Dec 2022 12:15:23 GMT
Subject: <i18n dev> RFR: 8296546: Add @spec tags to API [v4]
In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com>
 <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com>
Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com>

On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags.
>> 
>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec.
>> 
>> "Normalized" means...
>> * Use `https:` where possible (includes pretty much all cases)
>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site)
>> * Point to the root page of a multi-page spec
>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs)
>> 
>> In addition, a "standard" title is determined for all specs,  determined either from the content of the (main) spec page or from site index pages.
>> 
>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces.
>> 
>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR.
>> 
>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags.
>> 
>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/
>> 
>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Change ietf.org URLs to use rfc-editor.org
>  - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags
>  - Remove updates from unexported files
>  - Prefix RFC titles with `RFC NNNN:`
>  - JDK-8296547: Add @spec tags to API

I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 62:

> 60:      * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams
> 61:      * @see <a href="http://www.ietf.org/rfc/rfc919.txt">RFC&nbsp;929:
> 62:      * Broadcasting Internet Datagrams</a>

This `@see` line should now be removed since it's referencing the exact same document.

src/java.base/share/classes/java/net/StandardSocketOptions.java line 83:

> 81:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 82:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122
> 83:      * Requirements for Internet Hosts -- Communication Layers</a>

Same remark here: please remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 154:

> 152:      * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance
> 153:      * @see <a href="http://www.ietf.org/rfc/rfc1323.txt">RFC&nbsp;1323: TCP
> 154:      * Extensions for High Performance</a>

Remove the `@see`

src/java.base/share/classes/java/net/StandardSocketOptions.java line 186:

> 184:      *
> 185:      * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol
> 186:      * @see <a href="http://www.ietf.org/rfc/rfc793.txt">RFC&nbsp;793: Transmission

Remove the @see

src/java.base/share/classes/java/net/StandardSocketOptions.java line 377:

> 375:      * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers
> 376:      * @see <a href="http://www.ietf.org/rfc/rfc1122.txt">RFC&nbsp;1122:
> 377:      * Requirements for Internet Hosts -- Communication Layers</a>

Remove the @see

src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122:

> 120:  * @see <a
> 121:  * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609,
> 122:  * "Service Templates and <code>Service:</code> Schemes"</a>

The two `@see` should now be removed

-------------

Changes requested by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11073

From erikj at openjdk.org  Fri Dec  2 14:31:00 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Dec 2022 14:31:00 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v30]
In-Reply-To: <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
Message-ID: <Bz9N4O4qUKCuVAt7ZoAZl1FkR48qI6iKm_S0FiJDANs=.511266f5-95b3-4e0b-82f6-fb5730ecdae2@github.com>

On Wed, 23 Nov 2022 15:38:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > /issue add JDK-8296302
> 
> The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration.

Roger is correct, please do not add CSR issues with `/issue add`. The bot should auto discover CSRs if linked correctly in JBS. You need to `/issue remove` the CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Dec  2 16:51:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Dec 2022 16:51:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v32]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <U2ZZfoc2VKb3KdXhEy9dKR4yU6lUeawIDV9auD3nGkI=.fc56de1c-6752-4a41-ab64-6b33f784ad29@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - Requested changes #10
 - Requested changes #9
 - Requested changes #8
 - ... and 37 more: https://git.openjdk.org/jdk/compare/6065696e...581e0f7a

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=31
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: <i18n dev> RFR: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
Message-ID: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

-------------

Commit messages:
 - 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code

Changes: https://git.openjdk.org/jdk/pull/11489/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298045
  Stats: 308 lines in 78 files changed: 0 ins; 0 del; 308 mod
  Patch: https://git.openjdk.org/jdk/pull/11489.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11489/head:pull/11489

PR: https://git.openjdk.org/jdk/pull/11489

From ihse at openjdk.org  Fri Dec  2 16:52:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:52:16 GMT
Subject: <i18n dev> RFR: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <fFxu85P9b4eRFBowNuiSYQdyCA9OJvRPVPm5C_mqB70=.2b7eac64-ec95-49df-b3fd-cebcb18e674b@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: <i18n dev> Withdrawn: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:14:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:14:23 GMT
Subject: <i18n dev> RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files
Message-ID: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>

[JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.

To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).

That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.

When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.

The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

-------------

Commit messages:
 - 8298047: Remove all non-significant trailing whitespace from properties files

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298047
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

PR: https://git.openjdk.org/jdk/pull/11491

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From weijun at openjdk.org  Fri Dec  2 18:51:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 18:51:07 GMT
Subject: <i18n dev> RFR: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <xp58-oyXNmSSI1GSAZfCbYGVMUMRACd1cfBV8gUqwug=.757bf432-e9c8-4a80-abe9-d9f94cd45a12@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

Useless space. Should remove.

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: <i18n dev> RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Sat Dec  3 00:25:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 3 Dec 2022 00:25:08 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

Hi Andrew,
Thanks for taking on this. I think you can cherry-pick the relevant [CLDR changes](https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b) (under `common` directory) into this PR so that backporting would be easier.

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From serb at openjdk.org  Mon Dec  5 06:10:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:10:04 GMT
Subject: <i18n dev> RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <WPo83xTHqjvUb3Gn342Yy6RUZUjWaFk5kLVV5oJkaoo=.9f954462-1def-40fd-a38a-c74533cee090@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

The client changes look fine.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11491

From duke at openjdk.org  Mon Dec  5 07:05:03 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:05:03 GMT
Subject: <i18n dev> RFR: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <p7O7axVhjrW0uR55B1J3EgTaorzOkz7lU9wVQelsgbg=.5b4102ac-af17-4c53-98f9-c90081087bdf@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties line 281:

> 279: # Namespaces support
> 280: # 4. Using Qualified Names
> 281:         IllegalQName = L'\u00E9l\u00E9ment ou l'attribut ne correspond pas \u00E0 la production QName : QName::=(NCName':')?NCName.\u0020

XMLMessages.properties does not have a trailing space for IllegalQName. For consistency with the original, there should probably be no space (unless the original is incorrect).

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From andrew at openjdk.org  Mon Dec  5 14:38:51 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:38:51 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:

 - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
 - Update tzdata version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11438/files
  - new: https://git.openjdk.org/jdk/pull/11438/files/27bf9277..82d3453b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11438&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11438&range=00-01

  Stats: 23 lines in 5 files changed: 19 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11438.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11438/head:pull/11438

PR: https://git.openjdk.org/jdk/pull/11438

From andrew at openjdk.org  Mon Dec  5 14:46:11 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:46:11 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <2Izs6eygJONprQg5VmOp5atywmJqZgVJnccKqcjK918=.0184672c-fc38-4b4d-b3a8-71414eddeba7@github.com>
Message-ID: <r69Uj2Zj-LG6BFc5hhCc-e_-eSFgEHVOwQA_5DwCalc=.6efc12c0-2604-4bdd-943a-280f87b6b8e8@github.com>

On Fri, 2 Dec 2022 01:15:49 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> The following files need to be updated with the timezone data version. src/java.base/share/data/tzdata/VERSION test/jdk/java/util/TimeZone/TimeZoneData/VERSION

Good catch. I copied over the files from the tzdb bundle, but it seems they have `version` while we have `VERSION`. Fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From andrew at openjdk.org  Mon Dec  5 14:46:12 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 5 Dec 2022 14:46:12 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <0N9zRcGnG_U_tr8I9Qr2L9DM0Ex2qfztxbdVDDedgcU=.b9cd95e2-afce-4d3b-943c-2582e597c0a8@github.com>
Message-ID: <JvUQUDPjxgrO350Ps2PyoowCMvEKy856M5xFqKB-338=.bb9b6367-0699-417e-afea-939b75cb512b@github.com>

On Sat, 3 Dec 2022 00:21:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Andrew, Thanks for taking on this. I think you can cherry-pick the relevant [CLDR changes](https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b) (under `common` directory) into this PR so that backporting would be easier.

Good to see CLDR included them in good time. Now in this patch.

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From duke at openjdk.org  Mon Dec  5 19:50:15 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 19:50:15 GMT
Subject: <i18n dev> RFR: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <H-oM4Aas2MEYORLUsUE03ay3ewD3OLnFeTly7dQSesw=.f385a1ac-22c4-4645-a04d-d9a219ea8082@github.com>

On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the core-libs team.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties line 160:

> 158: xmlrch.errupdate = \u5EFA\u69CB\u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 159: xmlrch.errupdrow = \u66F4\u65B0\u5217\u6642\u767C\u751F\u932F\u8AA4: {0}
> 160: xmlrch.chars = \u5B57\u5143:\u0020

Likely not needed, since the original and all other l10n versions of RowSetResourceBundle.properties do not have a trailing space for `xmlrch.chars`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n\u0020\u0020

Likely a mistake, since as you stated, it is not in the format ?foo:\u0020? as there is a newline before the trailing spaces.

However if intentional it should probably be `FormatFailed = An internal error occurred while formatting the following message:\n\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 139:

> 137:         EncodingByteOrderUnsupported = Given byte order for encoding \"{0}\" is not supported.
> 138:         InvalidByte = Invalid byte {0} of {1}-byte UTF-8 sequence.
> 139:         ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020\u0020

Same here as well, either a mistake or should be ` ExpectedByte = Expected byte {0} of {1}-byte UTF-8 sequence.\u0020`

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 219:

> 217:         MSG_NOTATION_NAME_REQUIRED_FOR_UNPARSED_ENTITYDECL = The notation name is required after \"NDATA\" in the declaration for the entity \"{0}\".
> 218:         EntityDeclUnterminated = The declaration for the entity \"{0}\" must end with ''>''.
> 219: 	MSG_DUPLICATE_ENTITY_DEFINITION = Entity \"{0}\" is declared more than once.\u0020\u0020\u0020\u0020\u0020\u0020\u0020\u0020

Likely not intentional, but if it is then perhaps `MSG_DUPLICATE_ENTITY_DEFINITION = Entity "{0}" is declared more than once.\u0009` instead.

-------------

PR: https://git.openjdk.org/jdk/pull/11489

From naoto at openjdk.org  Mon Dec  5 20:40:05 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 20:40:05 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Have you run tests under `sun.util.calendar`? Tests like `TestZoneInfo310.java` sometimes fail with tzdata updates.

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From andrew at openjdk.org  Tue Dec  6 01:53:07 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 6 Dec 2022 01:53:07 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
 <N7uA6nzmUYfTOesVLna5uFv_p8g9FwgryUyaOCEacis=.97212a2c-04e5-484e-b38c-e992c4b79ec1@github.com>
Message-ID: <VGqJTczk37rsxgaaHnhvbFiXeDgy_WnIHAqMTHWJnY4=.6cafbd20-b403-43f9-9667-ff11741cb4a0@github.com>

On Mon, 5 Dec 2022 20:37:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Have you run tests under `sun.util.calendar`? Tests like `TestZoneInfo310.java` sometimes fail with tzdata updates.

Yes

~~~
Passed: sun/util/calendar/zi/Beyond2037.java
Passed: sun/util/calendar/zi/TestZoneInfo310.java
Passed: sun/util/calendar/Bug6653944.java
Passed: sun/util/calendar/Bug8176160.java
Passed: sun/util/calendar/CalendarSystemDeadLockTest.java
~~~

`sun/util` and `java/util` are also in `jdk_util_other` which is covered by `tier1_part2` in the PR checks: https://github.com/gnu-andrew/jdk/actions/runs/3621042294/jobs/6104922328#step:9:5925

Only `java.time` and `sun.text` are not covered by the PR (`tier2_part2`)

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From naoto at openjdk.org  Tue Dec  6 16:51:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 16:51:12 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <UcmSMlYIhAH0trJwDZhYIW7jaeA5VyPAzD6FkAoaEt8=.c8d7c08c-3198-4ba3-9cf4-bb4cb2a16dde@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Thanks for confirming. Looks good to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11438

From andrew at openjdk.org  Wed Dec  7 00:35:07 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 7 Dec 2022 00:35:07 GMT
Subject: <i18n dev> RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]
In-Reply-To: <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
 <LUd0Rb4G80fdee18UQItifokHjI6FI31GBVTmDu5m_M=.0dfca816-dae6-4276-ab67-6de9bec62081@github.com>
Message-ID: <Unca6SN4a77hWel3h1hBYboWA7XE4Efz1qcU845Afew=.2b15eb2d-a83f-4cc8-9dba-6da5cfb36795@github.com>

On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Update to the latest tzdata, 2022g.
>> 
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gains DST (CDT)
>> 
>> See bug for the full details.
>> 
>> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
>> 
>> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.
>
> Andrew John Hughes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add CLDR changes from https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b
>  - Update tzdata version

Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From andrew at openjdk.org  Wed Dec  7 00:37:02 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 7 Dec 2022 00:37:02 GMT
Subject: <i18n dev> Integrated: 8297804: (tz) Update Timezone Data to 2022g
In-Reply-To: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
References: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com>
Message-ID: <lxtmsWtPcoOMqDDxlLwiI_Y1CyvW8pZ9lMybE3b5JGY=.6e836cec-9dbc-46d8-b060-5dcfd84ed4fe@github.com>

On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Update to the latest tzdata, 2022g.
> 
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (CDT)
> 
> See bug for the full details.
> 
> There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715)
> 
> Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass.

This pull request has now been integrated.

Changeset: ce896731
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce896731d38866c2bf99cd49525062e150d94160
Stats:     240 lines in 26 files changed: 144 ins; 57 del; 39 mod

8297804: (tz) Update Timezone Data to 2022g

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/11438

From jpai at openjdk.org  Thu Dec  8 10:56:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 10:56:51 GMT
Subject: <i18n dev> RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
Message-ID: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>

Can I get a review of this change which fixes the copyright header on the test file?

-------------

Commit messages:
 - 8298375: Bad copyright header in test/jdk/java/lang/Character/Supplementary.java

Changes: https://git.openjdk.org/jdk/pull/11583/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11583&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298375
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11583.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11583/head:pull/11583

PR: https://git.openjdk.org/jdk/pull/11583

From alanb at openjdk.org  Thu Dec  8 11:03:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 11:03:27 GMT
Subject: <i18n dev> RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <I_yV8w3ai14-uQA7dTCgTz55AX8wee9lo6RhRFbhqbo=.1c6baa3a-8b38-4bce-924a-5358df5fa39c@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From jpai at openjdk.org  Thu Dec  8 11:03:29 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 11:03:29 GMT
Subject: <i18n dev> RFR: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <G5I7lTsec3LY-qrR5W-3epME8JassXh-iolUVqaUI0U=.77834a41-d4f5-4a6b-9293-5d5e6daa7263@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

Thank you Alan for the quick review. Local testing of this change shows that it works. I'll go ahead with the integration.

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From jpai at openjdk.org  Thu Dec  8 11:05:18 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Dec 2022 11:05:18 GMT
Subject: <i18n dev> Integrated: 8298375: Bad copyright header in
 test/jdk/java/lang/Character/Supplementary.java
In-Reply-To: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
References: <uc4QuWIL6wRZjFaYXti76MNr8Lht7qWqZAotNQvMBQU=.53588807-bffb-496a-8df9-9ebe906dfb0f@github.com>
Message-ID: <CUFmf5wnDJip_pKqiUchnSITwnBWFOQmPQ_p3Z_M2Dw=.1b6647ec-fc1e-421b-9c35-70bcce0b681b@github.com>

On Thu, 8 Dec 2022 10:48:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I get a review of this change which fixes the copyright header on the test file?

This pull request has now been integrated.

Changeset: 2f426cd6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f426cd68b28c8bf50b7102f961b15fd47b63b6a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8298375: Bad copyright header in test/jdk/java/lang/Character/Supplementary.java

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/11583

From naoto at openjdk.org  Wed Dec 14 23:21:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 23:21:44 GMT
Subject: <i18n dev> RFR: 8298808: Check `script` code on detecting the base
 locales
Message-ID: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>

Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

-------------

Commit messages:
 - 8298808: Check `script` code on detecting the base locales

Changes: https://git.openjdk.org/jdk/pull/11684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298808
  Stats: 12 lines in 2 files changed: 9 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11684/head:pull/11684

PR: https://git.openjdk.org/jdk/pull/11684

From naoto at openjdk.org  Wed Dec 14 23:47:43 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Dec 2022 23:47:43 GMT
Subject: <i18n dev> RFR: 8298808: Check `script` code on detecting the
 base locales [v2]
In-Reply-To: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
Message-ID: <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>

> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Allow Latin script by default

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11684/files
  - new: https://git.openjdk.org/jdk/pull/11684/files/28b01e21..9191b601

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11684&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11684/head:pull/11684

PR: https://git.openjdk.org/jdk/pull/11684

From joehw at openjdk.org  Thu Dec 15 17:13:08 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 Dec 2022 17:13:08 GMT
Subject: <i18n dev> RFR: 8298808: Check `script` code on detecting the
 base locales [v2]
In-Reply-To: <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
 <fCe2qY1mZZAih3y9VNmromWJLUrchaw-sm2VT1XqvuY=.dd45a913-3b68-40ab-935a-933e7020a1af@github.com>
Message-ID: <9FYcZP2z3NiwHxfLotUTZincXIrB2EdeM0l3B_pdQjU=.f02aab75-40e2-4b21-a0ce-c89e0b177fce@github.com>

On Wed, 14 Dec 2022 23:47:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow Latin script by default

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11684

From naoto at openjdk.org  Fri Dec 16 17:19:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Dec 2022 17:19:57 GMT
Subject: <i18n dev> Integrated: 8298808: Check `script` code on detecting
 the base locales
In-Reply-To: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
References: <-y3oZIKk1c7lLT9v6xYmNaOWr0aoKChLz5erO0Mx9vs=.02bc4c39-8d21-4aaa-ac95-0f7e28c21a43@github.com>
Message-ID: <OGwpeGkz8uVvzxeMc9GnFezFPoqUIcPKbHA48AImGGk=.8bf8e294-c167-4f09-847c-91a3a71491ee@github.com>

On Wed, 14 Dec 2022 23:08:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing `CLDRConverter` build tool to not regard [new locales](https://github.com/unicode-org/cldr/pull/2508/files#diff-94cbefde02914335da884f768063a06a84ad651ee4e56cdb1cb90625d7776731) introduced in CLDR 43 as one of the base locales. Otherwise they would incorrectly go into `java.base` module, then a test case fails.

This pull request has now been integrated.

Changeset: 0eeaeb8e
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0eeaeb8e7ba40be5e93eb87c7e3dc94230062746
Stats:     13 lines in 2 files changed: 10 ins; 1 del; 2 mod

8298808: Check `script` code on detecting the base locales

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/11684

From itakiguchi at openjdk.org  Wed Dec 21 16:05:25 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 16:05:25 GMT
Subject: <i18n dev> RFR: 8299194: CustomTzIDCheckDST.java may fail at future
 date
Message-ID: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
I used following standalone testcase

import java.util.Calendar;
import java.util.Date;
import java.util.SimpleTimeZone;

public class CheckDST {
????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
????public static void main(String args[]) throws Throwable {
????????runTZTest();
????}

????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
?????* This ensures the transition periods for Daylights Savings should be at March's last
?????* Sunday and October's last Sunday.
?????*/
????private static void runTZTest() {
????????Date time = new Date();
????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
????????????// We are in Daylight savings period.
????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
????????????????return;
????????} else {
????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
????????????????return;
????????}

????????// Reaching here means time zone did not match up as expected.
????????throw new RuntimeException("Got unexpected timezone information: " + time);
????}
}


I tested CheckDST with faketime, then I got following results

$ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
$ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
????????at CheckDST.runTZTest(CheckDST.java:28)
????????at CheckDST.main(CheckDST.java:8)


I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)

CustomTzIDCheckDST should run with daylight saving time.
Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`

Tested by standalone testcase

$ cat CheckDST1.java
import java.util.Calendar;
import java.util.Date;
import java.util.List;
import java.util.SimpleTimeZone;
import java.util.TimeZone;
import java.time.DayOfWeek;
import java.time.ZonedDateTime;
import java.time.temporal.TemporalAdjusters;
public class CheckDST1 {
    // Northern Hemisphere
    private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
    // Simulate Southern Hemisphere
    private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
    public static void main(String args[]) throws Throwable {
        runTZTest();
    }

    /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
     * This ensures the transition periods for Daylights Savings should be at March's last
     * Sunday and October's last Sunday.
     */
    private static void runTZTest() {
        Date time = new Date();
        String tzStr = System.getenv("TZ");
        if (tzStr == null)
            throw new RuntimeException("Got unexpected timezone information: TZ is null");
        boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
        TimeZone tz = new SimpleTimeZone(3600000, tzStr,
            nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
            Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
            nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
            Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
            3600000);
        System.out.println(time);
        if (tz.inDaylightTime(time)) {
            // We are in Daylight savings period.
            if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
                return;
        } else {
            if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
                return;
        }

        // Reaching here means time zone did not match up as expected.
        throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
    }

    private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
        return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
    }
}


Check Europe/Berlin timezone settings

$ zdump -v Europe/Berlin | grep 2023
Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600


Test results are as follows:

Northern Hemisphere side

$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Mar 26 01:59:59 MEZ 2023
$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Mar 26 01:59:59 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Mar 26 03:00:00 MESZ 2023
$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Mar 26 03:00:00 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Oct 29 02:59:59 MESZ 2023
$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Oct 29 02:59:59 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
Sun Oct 29 02:00:00 MEZ 2023
$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
Sun Oct 29 02:00:00 GMT+01:00 2023


Southern Hemisphere

$ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Mar 26 02:59:59 MESZ 2023
$bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Mar 26 02:59:59 GMT+02:00 2023

$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Mar 26 02:00:00 MEZ 2023
$ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Mar 26 02:00:00 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Oct 29 01:59:59 MEZ 2023
$ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Oct 29 01:59:59 GMT+01:00 2023

$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
Sun Oct 29 03:00:00 MESZ 2023
$ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
Sun Oct 29 03:00:00 GMT+02:00 2023

-------------

Commit messages:
 - 8299194: CustomTzIDCheckDST.java may fail at future date

Changes: https://git.openjdk.org/jdk/pull/11756/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299194
  Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11756.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11756/head:pull/11756

PR: https://git.openjdk.org/jdk/pull/11756

From naoto at openjdk.org  Wed Dec 21 20:56:50 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Dec 2022 20:56:50 GMT
Subject: <i18n dev> RFR: 8299194: CustomTzIDCheckDST.java may fail at
 future date
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>

On Wed, 21 Dec 2022 15:57:29 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

Thanks for the fix. Looks good overall. A couple of minor comments/questions.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 61:

> 59:     }
> 60: 
> 61:     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".

Probably adding "northern hemisphere" is helpful here.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 70:

> 68:         if (tzStr == null)
> 69:             throw new RuntimeException("Got unexpected timezone information: TZ is null");
> 70:         boolean nor = tzStr.matches(".*,M3\\..*,M10\\..*");

Do we need to use RegEx? A simple comparison with `CUSTOM_TZ` does not work?

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From itakiguchi at openjdk.org  Wed Dec 21 23:21:42 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 23:21:42 GMT
Subject: <i18n dev> RFR: 8299194: CustomTzIDCheckDST.java may fail at
 future date [v2]
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8299194: CustomTzIDCheckDST.java may fail at future date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11756/files
  - new: https://git.openjdk.org/jdk/pull/11756/files/a17d83d0..df2e8a86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11756&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11756.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11756/head:pull/11756

PR: https://git.openjdk.org/jdk/pull/11756

From itakiguchi at openjdk.org  Wed Dec 21 23:25:51 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 21 Dec 2022 23:25:51 GMT
Subject: <i18n dev> RFR: 8299194: CustomTzIDCheckDST.java may fail at
 future date [v2]
In-Reply-To: <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
 <DycgcJGMLRqXOU3WFz00H2PpX0eAYx7M1wA0jXHyllI=.006a128d-4cda-4db1-ba3d-82b6afe95a92@github.com>
Message-ID: <VfoUpM1KesqwredVnMK7Bb5obOaW_Eks7rIG6ZsPjYI=.75ab50c8-33a9-4300-9b5d-b52c459d7148@github.com>

On Wed, 21 Dec 2022 20:54:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8299194: CustomTzIDCheckDST.java may fail at future date
>
> Thanks for the fix. Looks good overall. A couple of minor comments/questions.

Thanks @naotoj .
I appreciate you suggestion.
Please review it again.

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From naoto at openjdk.org  Thu Dec 22 17:29:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Dec 2022 17:29:52 GMT
Subject: <i18n dev> RFR: 8299194: CustomTzIDCheckDST.java may fail at
 future date [v2]
In-Reply-To: <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
 <Uqhc4a1mr4igkK3RvMbKdsU9gNTSZ0APehejZAoIgfo=.cfa0aafb-4f76-4db7-afd2-00790b65b294@github.com>
Message-ID: <OEgcOztNqozclXfAuMpRchNBBVoCuM8Wn3X9_1Nj6iE=.37d8dae4-53f2-4cc9-ba6a-03f90adf27b3@github.com>

On Wed, 21 Dec 2022 23:21:42 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
>> I used following standalone testcase
>> 
>> import java.util.Calendar;
>> import java.util.Date;
>> import java.util.SimpleTimeZone;
>> 
>> public class CheckDST {
>> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
>> ????public static void main(String args[]) throws Throwable {
>> ????????runTZTest();
>> ????}
>> 
>> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
>> ?????* This ensures the transition periods for Daylights Savings should be at March's last
>> ?????* Sunday and October's last Sunday.
>> ?????*/
>> ????private static void runTZTest() {
>> ????????Date time = new Date();
>> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
>> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
>> ????????????// We are in Daylight savings period.
>> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>> ????????????????return;
>> ????????} else {
>> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>> ????????????????return;
>> ????????}
>> 
>> ????????// Reaching here means time zone did not match up as expected.
>> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
>> ????}
>> }
>> 
>> 
>> I tested CheckDST with faketime, then I got following results
>> 
>> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
>> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
>> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
>> ????????at CheckDST.runTZTest(CheckDST.java:28)
>> ????????at CheckDST.main(CheckDST.java:8)
>> 
>> 
>> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
>> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
>> 
>> CustomTzIDCheckDST should run with daylight saving time.
>> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
>> 
>> Tested by standalone testcase
>> 
>> $ cat CheckDST1.java
>> import java.util.Calendar;
>> import java.util.Date;
>> import java.util.List;
>> import java.util.SimpleTimeZone;
>> import java.util.TimeZone;
>> import java.time.DayOfWeek;
>> import java.time.ZonedDateTime;
>> import java.time.temporal.TemporalAdjusters;
>> public class CheckDST1 {
>>     // Northern Hemisphere
>>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>>     // Simulate Southern Hemisphere
>>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>>     public static void main(String args[]) throws Throwable {
>>         runTZTest();
>>     }
>> 
>>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>>      * This ensures the transition periods for Daylights Savings should be at March's last
>>      * Sunday and October's last Sunday.
>>      */
>>     private static void runTZTest() {
>>         Date time = new Date();
>>         String tzStr = System.getenv("TZ");
>>         if (tzStr == null)
>>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>>             3600000);
>>         System.out.println(time);
>>         if (tz.inDaylightTime(time)) {
>>             // We are in Daylight savings period.
>>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>>                 return;
>>         } else {
>>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>>                 return;
>>         }
>> 
>>         // Reaching here means time zone did not match up as expected.
>>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>>     }
>> 
>>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>>     }
>> }
>> 
>> 
>> Check Europe/Berlin timezone settings
>> 
>> $ zdump -v Europe/Berlin | grep 2023
>> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
>> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
>> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
>> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
>> 
>> 
>> Test results are as follows:
>> 
>> Northern Hemisphere side
>> 
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Mar 26 01:59:59 MEZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Mar 26 01:59:59 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Mar 26 03:00:00 MESZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Mar 26 03:00:00 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Oct 29 02:59:59 MESZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Oct 29 02:59:59 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
>> Sun Oct 29 02:00:00 MEZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
>> Sun Oct 29 02:00:00 GMT+01:00 2023
>> 
>> 
>> Southern Hemisphere side
>> 
>> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Mar 26 02:59:59 MESZ 2023
>> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Mar 26 02:59:59 GMT+02:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Mar 26 02:00:00 MEZ 2023
>> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Mar 26 02:00:00 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Oct 29 01:59:59 MEZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Oct 29 01:59:59 GMT+01:00 2023
>> 
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
>> Sun Oct 29 03:00:00 MESZ 2023
>> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
>> Sun Oct 29 03:00:00 GMT+02:00 2023
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8299194: CustomTzIDCheckDST.java may fail at future date

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11756

From itakiguchi at openjdk.org  Thu Dec 22 21:09:53 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 22 Dec 2022 21:09:53 GMT
Subject: <i18n dev> Integrated: 8299194: CustomTzIDCheckDST.java may fail at
 future date
In-Reply-To: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
References: <WLaw7cFwSjOG5fYL5QXPjGUxemrk37_SN2fSBxFkmjY=.e2602944-b688-4d04-98e3-5b0ec0fa787c@github.com>
Message-ID: <NOhSk2Ag9ccfBz_XLDMH6P3SyIMB3KyrCbZX8RkyN5U=.a55d087a-b5fb-45d6-9380-660f60e2f9e0@github.com>

On Wed, 21 Dec 2022 15:57:29 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
> 
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
> 
> public class CheckDST {
> ????private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
> ????public static void main(String args[]) throws Throwable {
> ????????runTZTest();
> ????}
> 
> ????/* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0".
> ?????* This ensures the transition periods for Daylights Savings should be at March's last
> ?????* Sunday and October's last Sunday.
> ?????*/
> ????private static void runTZTest() {
> ????????Date time = new Date();
> ????????if (new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0,
> ????????????????Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(time)) {
> ????????????// We are in Daylight savings period.
> ????????????if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????} else {
> ????????????if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
> ????????????????return;
> ????????}
> 
> ????????// Reaching here means time zone did not match up as expected.
> ????????throw new RuntimeException("Got unexpected timezone information: " + time);
> ????}
> }
> 
> 
> I tested CheckDST with faketime, then I got following results
> 
> $ TZ=GMT faketime -m "2023-03-25 22:59:59" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> $ TZ=GMT faketime -m "2023-03-25 23:00:00" env TZ="MEZ-1MESZ,M3.5.0,M10.5.0" $HOME/jdk-21-b02/bin/java CheckDST
> Exception in thread "main" java.lang.RuntimeException: Got unexpected timezone information: Sun Mar 26 00:00:00 GMT+01:00 2023
> ????????at CheckDST.runTZTest(CheckDST.java:28)
> ????????at CheckDST.main(CheckDST.java:8)
> 
> 
> I assume `TZ=MEZ-1MESZ`refers Europe/Berlin timezone.
> In this case, `TZ` environment variable should be `MEZ-1MESZ,M3.5.0,M10.5.0/3` (`/3` is missing in testcase)
> 
> CustomTzIDCheckDST should run with daylight saving time.
> Add Simulate Southern Hemisphere by `MEZ-1MESZ,M10.5.0,M3.5.0/3`
> 
> Tested by standalone testcase
> 
> $ cat CheckDST1.java
> import java.util.Calendar;
> import java.util.Date;
> import java.util.List;
> import java.util.SimpleTimeZone;
> import java.util.TimeZone;
> import java.time.DayOfWeek;
> import java.time.ZonedDateTime;
> import java.time.temporal.TemporalAdjusters;
> public class CheckDST1 {
>     // Northern Hemisphere
>     private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0/3";
>     // Simulate Southern Hemisphere
>     private static String CUSTOM_TZ2 = "MEZ-1MESZ,M10.5.0,M3.5.0/3";
>     public static void main(String args[]) throws Throwable {
>         runTZTest();
>     }
> 
>     /* TZ code will always be set to "MEZ-1MESZ,M3.5.0,M10.5.0/3".
>      * This ensures the transition periods for Daylights Savings should be at March's last
>      * Sunday and October's last Sunday.
>      */
>     private static void runTZTest() {
>         Date time = new Date();
>         String tzStr = System.getenv("TZ");
>         if (tzStr == null)
>             throw new RuntimeException("Got unexpected timezone information: TZ is null");
>         boolean nor = tzStr.matches(".*,M3\..*,M10\..*");
>         TimeZone tz = new SimpleTimeZone(3600000, tzStr,
>             nor ? Calendar.MARCH : Calendar.OCTOBER, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             nor ? Calendar.OCTOBER : Calendar.MARCH, -1,
>             Calendar.SUNDAY, 3600000, SimpleTimeZone.UTC_TIME,
>             3600000);
>         System.out.println(time);
>         if (tz.inDaylightTime(time)) {
>             // We are in Daylight savings period.
>             if (time.toString().endsWith("GMT+02:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         } else {
>             if (time.toString().endsWith("GMT+01:00 " + Integer.toString(time.getYear() + 1900)))
>                 return;
>         }
> 
>         // Reaching here means time zone did not match up as expected.
>         throw new RuntimeException("Got unexpected timezone information: " + tzStr + " " + time);
>     }
> 
>     private static ZonedDateTime getLastSundayOfMonth(ZonedDateTime date) {
>         return date.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY));
>     }
> }
> 
> 
> Check Europe/Berlin timezone settings
> 
> $ zdump -v Europe/Berlin | grep 2023
> Europe/Berlin  Sun Mar 26 00:59:59 2023 UTC = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
> Europe/Berlin  Sun Mar 26 01:00:00 2023 UTC = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 00:59:59 2023 UTC = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
> Europe/Berlin  Sun Oct 29 01:00:00 2023 UTC = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
> 
> 
> Test results are as follows:
> 
> Northern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Mar 26 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Mar 26 03:00:00 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:59:59 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 date
> Sun Oct 29 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M3.5.0,M10.5.0/3 java CheckDST1
> Sun Oct 29 02:00:00 GMT+01:00 2023
> 
> 
> Southern Hemisphere side
> 
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:59:59 GMT+02:00 2023
> 
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Mar 26 02:00:00 MEZ 2023
> $ TZ=GMT faketime -m '2023-03-26 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Mar 26 02:00:00 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 01:59:59 MEZ 2023
> $ TZ=GMT faketime -m '2023-10-29 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 01:59:59 GMT+01:00 2023
> 
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 date
> Sun Oct 29 03:00:00 MESZ 2023
> $ TZ=GMT faketime -m '2023-10-29 01:00:00' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3 java CheckDST1
> Sun Oct 29 03:00:00 GMT+02:00 2023

This pull request has now been integrated.

Changeset: 5e2de896
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e2de89628aaf6acb8e458fb417426ca5e477bea
Stats:     21 lines in 1 file changed: 16 ins; 0 del; 5 mod

8299194: CustomTzIDCheckDST.java may fail at future date

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/11756

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

-------------

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: <i18n dev> RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10029