RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
Roger.Riggs at Oracle.com
Wed Apr 29 13:31:14 UTC 2015
Point taken about the constructor and that should have a spec
clarification to ignore the nanoseconds.
The issue is tracked with:
ZoneOffsetTransition constructor should ignore nanoseconds
With that, the compareTo method can be simpler. The rest looks fine.
On 4/29/2015 5:33 AM, Peter Levart wrote:
> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>> One additional change is needed. The compareTo() method can rely on
>> the new epochSecond field as well.
>> Otherwise good!
> Hi Stephen,
> LocalDateTime (transition) has nanosecond precision. It may be that
> transitions loaded from file in ZoneRules only have second precisions,
> but ZoneOffsetTransition is a public class with public factory method
> that takes a LocalDateTime transition parameter, so I think
> compareTo() can't rely on epochSecond alone. But epochSecond can be
> used as optimization in compareTo() as well as equals():
> An alternative to keeping epochSecond field in ZoneOffsetTransition
> would be to keep a reference to Instant instead. Instant contains an
> epochSecond field (as well as nanos) and could be used for both
> toEpochSecond() and getInstant() methods.
> What do you think?
> It also occurred to me that serialization format of
> ZoneOffsetTransition is not adequate currently as it looses nanosecond
> Regards, Peter
>> On 27 April 2015 at 17:24, Peter Levart <peter.levart at gmail.com> wrote:
>>> Hi again,
>>> Here's another optimization to be reviewed that has been discussed a
>>> ago (just rebased from webrev.01) and approved by Stephen:
>>> The discussion about it is intermingled with the ZoneId.systemDefault()
>>> discussion and starts about here:
>>> The rationale for the optimization is speeding-up the conversion
>>> from epoch
>>> time to LocalDateTime. This conversion uses
>>> where there is a loop over ZoneOffsetTransition array that
>>> searches for
>>> 1st transition that has its toEpochSecond value less than the Instant's
>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>>> epochSecond. This repeated conversion is unnecessary, as
>>> ZoneOffsetTransition array is part of ZoneRules which is cached.
>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>> LocalDateTime variant and eposhSecond variant of transition time as the
>>> object's state) speeds up this conversion.
>>> Regards, Peter
More information about the core-libs-dev