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.ri...@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.ri...@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
>>>>>>
>
