On Fri, 25 Mar 2022 14:28:41 GMT, Claes Redestad <redes...@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
