On Thu, 30 Jun 2022 18:32:56 GMT, Gaurav Chaudhari <d...@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: >>  > > 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
