FULL PRODUCT VERSION :
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
FULL OS VERSION :
SunOS buildserver 5.6 Generic_105181-32 sun4u sparc SUNW,Ultra-5_10 and
SunOS qa-netra1 5.8 Generic_108528-10 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
A DESCRIPTION OF THE PROBLEM :
The TimeZone.getDefault().getID() call returns different string when running on different OS. When the attached java program is running on Solaris using jre1.4.2, it prints "US/Eastern" while running the same code with jre1.4.2 on Windows, it prints "America/New_York".
The actual problem I am encountering is that my server generate this TimeZoneID while the client applet will base on this ID to re-create the TimeZone object. The problem is if the client applet is running jre1.3.1 plugin, it does not understand the string "US/Eastern" and hence the timezone creation is wrong. If I use jre1.4.1 (or later) plugin, it understand "US/Eastern" and re-create the correct TimeZone.
Since we still support 1.3.1 plugin, we will experience the problem if we can't get a fix on this or we'll have to bump up the plugin support.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached...
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
"America/New_York" get printed instead of "US/Eastern" when running on Solaris using jre1.4.2.
ACTUAL -
I want to see "America/New_York" instead of "US/Eastern" when running jre1.4.2 on Solaris ...
Or fix 1.3.1_09 (I tried 1.3.1_02 and 1.3.1_09) so it understands "US/Eastern" and gives me the correct TimeZone.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/*=============== Save as TestTimeZone.java and run on Solaris and Win32 to
see the different output...
*/
import java.util.*;
public class TestTimeZone {
public static void main(String[] args) {
System.out.println("TimeZone.getDefault().getID() = " + TimeZone.getDefault().getID());
}
}
---------- END SOURCE ----------
Release Regression From : 1.3.1
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.
###@###.### 2005-03-04 04:13:31 GMT