JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

[Stephen Colebourne]

No, the opposite. Those rules that do NOT have a fixed offset.

ZoneId.of("Europe/London") should be cached, but not
ZoneId.of("UTC+10:00"). Note that the latter is an offset-based
ZoneRegion, not a ZoneOffset.

Stephen


On 24 April 2015 at 14:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Stephen,
>
> Just to clarify, by non-offset based ZoneRules do you mean it has a fixed
> offset
> meaning no transitions; aka ZoneRules.isFixedOffset() = true?
>
> Thanks, Roger
>
>
>
> On 4/24/2015 5:32 AM, Stephen Colebourne wrote:
>>
>> The code in the webrev changes the behaviour of java.time, so cannot go
>> in.
>>
>> Run this code:
>>      TimeZone zone = TimeZone.getDefault();
>>      System.out.println(zone);
>>      ZoneId zoneId = ZoneId.systemDefault();
>>      System.out.println(zoneId);
>>      TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris"));
>>      TimeZone zone2 = TimeZone.getDefault();
>>      System.out.println(zone2);
>>      ZoneId zoneId2 = ZoneId.systemDefault();
>>      System.out.println(zoneId2);
>>
>> before and after this change, a difference will be seen. Specifically,
>> ZoneId.systemDefault() responds to a change to TimeZone.setDefault().
>>
>> The correct fix to this issue was outlined in the bug report.
>>
>> 1) add caching for those ZoneRegion instances that have a non-offset
>> based underlying ZoneRules. This would be done in ZoneRegion.ofId().
>> Those instances of ZoneRegion created by ZoneId.ofOffset() would not
>> be cached.
>> 2) Add a Clock instance variable to ZoneId that is only non-null if
>> the object is cached
>> 3) Change Clock.system(ZoneId) to check to see if the clock in the
>> ZoneId is non-null before creating a new instance.
>>
>> Stephen
>>
>>
>>
>> On 23 April 2015 at 22:28, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>> Hi Peter,
>>>
>>> Setting the user.timezone property doesn't reset the value returned from
>>> getDefaultRef().
>>> You can see the new value through java.util.TimeZone but not through
>>> java.time.ZoneId.
>>>
>>> Its a bad idea to allow the default timezone change and in java.time it
>>> was
>>> purposefully
>>> handled as an initialize once value.
>>>
>>> Roger
>>>
>>>
>>>
>>> On 4/23/2015 5:20 PM, Peter Levart wrote:
>>>>
>>>>
>>>>
>>>> On 04/23/2015 10:33 PM, Roger Riggs wrote:
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> The defaultTimeZone is cached in java.util.TimeZone the first time it
>>>>> is
>>>>> referenced
>>>>> and is not updated after that.  See java.util.TimeZone.getDefaultRef().
>>>>>
>>>>> Regards, Roger
>>>>>
>>>> But any code (with enough privilege) can update it:
>>>>
>>>> abstract public class TimeZone .... {
>>>>
>>>>      public static void setDefault(TimeZone zone)
>>>>      {
>>>>          SecurityManager sm = System.getSecurityManager();
>>>>          if (sm != null) {
>>>>              sm.checkPermission(new PropertyPermission
>>>>                                 ("user.timezone", "write"));
>>>>          }
>>>>          defaultTimeZone = zone;
>>>>      }
>>>>
>>>>
>>>>
>>>> Peter
>>>>
>>>>> On 4/23/2015 4:11 PM, Peter Levart wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 04/23/2015 09:53 PM, nadeesh tv wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please review this minor change which  optimized
>>>>>>> Clock.systemDefaultZone() and Clock.system(ZoneId)  to avoid creating
>>>>>>> new
>>>>>>> instance of Clock.SystemClock every time they are called.
>>>>>>>
>>>>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8074023
>>>>>>>
>>>>>>> Webrev : http://cr.openjdk.java.net/~rriggs/nadeesh-tv-8074023/
>>>>>>>
>>>>>> Hi Nadeesh,
>>>>>>
>>>>>> What happens if ZondeId.systemDefault() changes
>>>>>> (TimeZone.setDefault())
>>>>>> *after* Clock class has already been initialized?
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>