RFR: 8283681: Improve ZonedDateTime offset handling [v2]

[Roger Riggs]

On Fri, 25 Mar 2022 14:28:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/ZoneRegion.java line 183:
>> 
>>> 181:     @Override
>>> 182:     /* package-private */ ZoneOffset getOffset(long epochSecond) {
>>> 183:         return getRules().getOffset(Instant.ofEpochSecond(epochSecond));
>> 
>> The nanoAdjustment passed to `ofEpochSecond` is discarded in this code.
>> It may be larger than a second;  see `Instant.ofEpochSecond(sec, nano)` for the details.
>> Adding a second parameter to the `getOffset` method could be the remedy.
>
> Done.
> 
> Sadly it seems the smaller improvement I got on `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in `Instant.ofEpochSecond(sec, nanos)`:
> 
> Benchmark                                     Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset     thrpt   15  27.579 ? 0.030  ops/ms
> GetYearBench.getYearFromMillisZoneRegion     thrpt   15   9.570 ? 0.091  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC  thrpt   15  28.063 ? 0.030  ops/ms
> 
> Benchmark                                     Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset     thrpt   15  34.791 ? 0.030  ops/ms
> GetYearBench.getYearFromMillisZoneRegion     thrpt   15   9.526 ? 0.122  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC  thrpt   15  28.056 ? 0.040  ops/ms
> 
> 
> `getYearFromMillisZoneOffset` is still good.

I would expect that `nanoAdjustment` is zero in most cases, would it hurt performance to test for zero and skip the math?

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

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