FULL PRODUCT VERSION :
robo@saiph:~/src/bios$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
robo@saiph:~/src/bios$ uname -a
Linux saiph 2.6.27-7-generic #1 SMP Thu Oct 30 04:18:38 UTC 2008 i686 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
Using several threads to load pack200 files can set the default timezone information to utc.

UnpackerImpl.unpack looks something like this:
-------------------------------------------------------
TimeZone tz = TimeZone.getDefault();
try {
  TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
   ... do some stuff ...
} finally {
  TimeZone.setDefault(tz);
}
--------------------------------------------------------

If a second thread enter unpack while a first thread is inside the try-block, then that second
thread will get tz=UTC (and later on set default to UTC, in the finally).

UnpackerImpl.unpack should not set a default timezone, if it needs to calculate timezone distances it should do just that, get a time delta between current time and UTC.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We have an applet that uses a lot of different jar files. The jar files are arranged in an order that makes the applet start by loading only the first pack200/jar-file. Once the applet has started it starts a thread that loads the other pack200/jar-files on a background thread. If the user starts to do actions the normal class loading occurrs on the edt.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correct timezone every time.

ACTUAL -
Sometimes we get date information that differ from the expected value.

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
1) Stop using our background thread to pre-load the other jar-files. This of course means that the user will
    get a slower loading system.

2) use webstart (which we can do as well).