JDK-6236035 : (tz) REGRESSION: TimeZone.getID() on Solaris jre1.4.2 returns different ID from Win32
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2005-03-04
  • Updated: 2010-07-29
  • Resolved: 2005-05-25
Related Reports
Relates :  
Description
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

Comments
WORK AROUND Probably the easiest way to work around the problem is to provide the latest zoneinfo using zic and use the more recent time zone IDs. Otherwise, links can be created to support the new time zone IDs, such as America/Los_Angeles. The following is the list of US/* and America/* that are identical. Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa ###@###.### 2005-05-25 13:13:43 GMT
25-05-2005

EVALUATION This change was intentional to fix 4495052. Solaris 8 supports the old subset of the time zones defined in the public tz database. On Solaris (and Linux), it's expected to return the same time zone ID as it's defined on the platform. ###@###.### 2005-05-25 13:13:43 GMT
25-05-2005