On Tue, 10 Sep 2024 05:46:46 GMT, Jaikiran Pai wrote:
>> I pushed the review suggestions. There were two GitHub Actions failures on
>> `macos-aarch64`, but they look to be occurrences of this existing bug:
>> https://bugs.openjdk.org/browse/JDK-8247940.
>
> Hello @fitzsim, I plan to take a loo
On Mon, 2 Sep 2024 16:02:31 GMT, Andrew John Hughes wrote:
>> fitzsim has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> BootClassPathZipFileTest: Switch to createClassBytes, createZip static
>> functions
&
On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim wrote:
>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit
> since the last revision:
>
> BootClassPathZipFileTest: Switch to createClassBytes, createZip stati
On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade wrote:
>> Updated all the tests that depend on external infrastructure services as
>> manual. These tests may fail with external reasons, for instance - change in
>> CA test portal, certificate status updates, or network issues.
>
> Rajan Halade ha
On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato wrote:
>> Pleases review this PR.
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in
>> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
>> ar
On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes 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/
On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes 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 `Am
On Mon, 5 Dec 2022 20:37:31 GMT, Naoto Sato 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/cal
On Sat, 3 Dec 2022 00:21:21 GMT, Naoto Sato 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 backport
On Fri, 2 Dec 2022 01:15:49 GMT, Yoshiki Sato 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
ttps://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 chang
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
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
I've opened https://bugs.openjdk.org/browse/JDK-82938
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Interesting, I remember changes like this causing fai
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
That is something we've patched locally e.g.
https:/
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Should this not have included an update to the resour
16 matches
Mail list logo
