RFR: 8073394: Clock.systemUTC() should return a constant

[Daniel Fuchs]

Hi Peter,

On 24/02/15 10:00, Stephen Colebourne wrote:
> On 23 February 2015 at 22:27, Peter Levart <peter.levart at gmail.com> wrote:
>> What about the following idea:
>>
>> - create a (maybe still package-private) instance method
>> ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the
>> ZoneId.
>> - Clock.system(ZoneId) static method is then just delegating to
>> ZoneId.getSystemClock().
>> - Similarly Clock.systemDefaultZone() can just return
>> ZoneId.defaultSystem().getSystemClock().
>> - Similarly Clock.systemUTC() can just return
>> ZoneOffset.UTC.getSystemClock().
>>
>> Or do we just want to cache systemUTC() Clock here?
>
> I suspect that the above would be a good optimisation, though perhaps
> a separate issue?

I agree with Stephen here.

There is an immediate value in having Clock.systemUTC() always
return the same clock.

I believe it could also be good for Clock.systemDefaultZone() to
always return the same clock as long as the default zone doesn't
change - and what you are proposing would solve this issue.
It was bothering me that Clock.systemUTC() could be optimized
but Clock.systemDefaultZone() could not.

But I'd rather handle that in a separate issue.
I'd like to understand all the implications of having
ZoneId depend on Clock, and whether it's worth it to
have an additional Clock field in all instances of ZoneId.

best regards,

-- daniel

>
> Stephen
>