views:

120

answers:

2

What happens if #setDefault(TimeZone timezone) is called by a concurrent application running on the same application server with JDK 1.6

As discussed in TimeZone #setDefault changes in JDK 6 the call now changes VM wide, this can have horrible consequences.

If you're not adminsitrating the application server, how to ensure TimeZone doesn't change?

+3  A: 

My suggestion would be to ignore the default time zone completely. Always specify the time zone you want to use, making it a lot harder to accidentally use something that's meaningful to you instead of the user. Indeed, for Noda Time we've removed everything that defaults the time zone.

Obligatory Joda reference: I'd also suggest using Joda Time instead of the built-in date/time APIs.

Jon Skeet
Yes, i also suggest using Joda Time, but unfortunately its not possible (in my case). Does the default application servers using the `SecurityManager` and avoid setting `user.timezone`?
codedevour
@chrsk: I don't know, to be honest. Even without using Joda Time you can try to make sure you always specify the time zone whenever it's relevant though. Could you give more details about your situation?
Jon Skeet
A: 

The way to prevent TimeZone.setDefault(...) from having VM-wide effect is to make sure that your SecurityManager does NOT give applications permission to write the "user.timezone" system property.

To understand why, look at the source code.

Now, it is arguably a bit naughty to rely on behavior that is not documented in the Javadoc. But in this case we have little choice. Besides, given the history of this particular method, the Sun / Oracle engineers are unlikely to change its behavior ... yet again.

Stephen C