<i18n dev> RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v6]

[Gaurav Chaudhari]

On Thu, 2 Jun 2022 18:07:39 GMT, Naoto Sato <naoto at openjdk.org> 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 several runs of CI tests and found no failures. Sorry for the false alarm. BTW, now I've looked the test more closely, the test can be simplified by using `SimpleTimeZone`, such as:
> 
>  new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())
> 
> This piece will check the current date is in DST, emulating `TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

Hi @naotoj , 
Thanks for revisiting that and confirming it is all good. Initially the problem was brought to my attention through a third party client utilizing this particular TZ code, and that is where we got the basis for the need of the fix, where we are bypassing typical tzdb access to find named Timezones such as "Europe/Belgium" and trying to find the GMT offset and computing the time.

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? This sounds perfectly fine as long as SimpleTimeZone is have the zone ID setup exactly as the `MEZ-1MESZ,M3.5.0,M10.5.0` indicated. I can try this out ... just wanted to confirm with you how to make use of the above instantiation.

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

PR: https://git.openjdk.java.net/jdk/pull/8661