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
