On 4/23/15 11:28 PM, Roger Riggs 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
On 04/24/2015 11: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);
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
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
On 4/23/2015 4:11 PM, Peter Levart wrote:
On 04/23/2015 09:53 PM, nadeesh tv wrote:
Hi all,
Please review
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 :
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
