Re: Default timezone changes out of nowhere?

Werner Lehmann wrote: 
Hi Andrew,

On 30.06.2005 02:14, Andrew Thompson wrote:

What happens if you call TimeZone.setDefault(null)
in that instance?  Does the timezone revert to Amrc/Dnvr,
or is it stuck at UTC?


I see, calling setDefault() with a null parameter will re-init the timezone from the OS again - unless this mechanism does not work anymore or the tz on the OS has become UTC, too.

...Is it somehow possible to tap into the JDK method Timezone.setDefault(), e.g. to log a stack trace, in order to learn what is executing this? 



Explicitly check for the change in a separate thread and
throw a new Exception() when it occurs?


We already see in the log4j log when the change occurs. Throwing an exception does not achieve anything else, does it? I mean we still do not know who called .setDefault(). I was hoping maybe there was some debugging tool available which could do this.

Well, a debugger could put a breakpoint on the method if that's what you desire.


Admittedly the new thread might poll more often and detect the change sooner. We are not even sure which one of the RMI server, 3rd party jars, servlets... etc could be causing this, and to further add to the trouble, it only occurs in the production environment.


Are you sure that the value returned by the method can only be changed from within the JVM? What I'm getting at is, is it possible some other process is changing some OS level setting and that is being propagated down into the JVM?

Ray

--
XML is the programmer's duct tape.
.