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

Naoto Sato naoto at openjdk.org
Thu Jun 30 20:10:44 UTC 2022

On Thu, 30 Jun 2022 18:32:56 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
>> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
>> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
>> _(where 7200 represents 7200 seconds -> +2 hour offset)_
>> Sample output:
>> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
>   8288377: Simplified TZ offset calc and consolidate MACOS impl.

src/java.base/unix/native/libjava/TimeZone_md.c line 569:

> 567:     }
> 568: 
> 569:     strftime(offset, 6, "%z", &localtm);

Return value has to be examined. If it is not `5`, then I'd expect falling back to "GMT".

src/java.base/unix/native/libjava/TimeZone_md.c line 572:

> 570:     char gmt_offset[] = {offset[0], offset[1], offset[2], ':', offset[3], offset[4], '\0'};
> 571: 
> 572:     sprintf(buf, (const char *)"GMT%s", gmt_offset);

You could use the format string as "GMT%c%c%c:%c%c" so that the extra `gmt_offset` variable can be eliminated.


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

More information about the i18n-dev mailing list