On Fri, 27 May 2022 18:40:32 GMT, XenoAmess wrote:
>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> do it as naotoj said
Changes to `net` and `http` look good.
-
Marked as reviewed by dfuchs (Reviewe
On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari wrote:
>> This fix ensures that when a lookup for a custom TZ code fails, and an
>> attempt is made to find the GMT offset in order to get the current time,
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pu
On Thu, 2 Jun 2022 18:07:39 GMT, Naoto Sato wrote:
>> Gaurav Chaudhari has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8285838: Cleanup of trailing whitespace
>> - 8285838: Corrected month comparison check for TZ DST
>
> I tried sever
On Thu, 2 Jun 2022 18:14:55 GMT, Gaurav Chaudhari wrote:
> Is the suggestion here to substitute the setting of the TZ environment
> variable, and simply getting a date based off this `SimpleTimeZone` , so as
> to bypass the process creation and just have it as a more simpler test?
No. The test
On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato wrote:
> Refactoring some old code in locale providers. The test case data have also
> been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not
> handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()`
