JDK-4212004 : TimeZone.getDefault() fails for EST time zone in Australia
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 2.0.1,1.1.7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.6,solaris_7
  • CPU: sparc
  • Submitted: 1999-02-16
  • Updated: 1999-09-13
  • Resolved: 1999-09-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 kestrelFixed
Related Reports
Relates :  
Relates :  
Description
I've included a simple test case below.  Apparently, Australia also has a time zone know as "EST", the same id used for the US Eastern Standard Time.  When an app needs to display a date/time value in Australia's "EST", it displays the date/time using the US "EST".

import java.util.*;
import java.text.*;

class Test {
    public static void main(String[] args) {
        SimpleDateFormat fm = new SimpleDateFormat("MMM d  HH:mm:ss");
        fm.setTimeZone(TimeZone.getDefault());
        System.out.println("Date/time is: " + fm.format(new Date()));
    }
}

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: kestrel
14-06-2004

EVALUATION This is not a bug. The programmatic ID, "EST" in this case, will always return a fixed time zone. "EST" always returns US Eastern Time. There is a separate identifier for the Australian zone in question. In 1.2 it is recommended that long zone names (e.g., Europe/London) be used to avoid ambiguity. alan.liu@eng 1999-03-02 The test program gives the following results on Solaris (in C locale). darkwing> env TZ=Australia/Queensland date Tue Mar 16 22:31:55 EST 1999 darkwing> env TZ=US/Eastern date Tue Mar 16 07:31:58 EST 1999 darkwing> env TZ=Australia/Queensland /usr/local/java/jdk1.2.1/solaris/bin/java Test Date/time is: Mar 16 23:32:02 darkwing> env TZ=Australia/Queensland /usr/local/java/jdk1.1.8/solaris/bin/java Test Date/time is: Mar 16 23:32:07 There is no time zone name parsing involved at the application level. I think this is a bug. Not fixed in JDK 1.2, either. It's not using US EST, though. masayoshi.okutsu@Eng 1999-03-16 peter.scott@Eng 1999-03-16 The original problem was logged from one of our Australian customers. According to them, all of the dates/times they were seeing in our application appeared in US EST instead of Australian EST. This problem must have occurred before. Any known workarounds for jdk 1.1.6 would be appreciated. Here's what I'm seeing on recent promoted builds: >> bash$ echo $TZ Australia/Queensland bash$ date Sat Mar 20 05:28:54 EST 1999 bash$ /usr/local/java/jdk1.1.8/solaris/bin/java date AET / Mar 20 06:28:47 bash$ /usr/local/java/jdk1.2.1/solaris/bin/java date Australia/Sydney / Mar 20 06:27:54 << This bug has been fixed by the fixes for 4167800 and 4059431. Why does it still deviate from the info shown by 'date'? Because of a bug in Solaris (at least in SunOS 5.6): The Java VM determines the zone using two pieces of information: The 'timezone' variable, which is reported as -36000, or GMT+10:00, and the 'daylight' variable. For Australia/Queensland, we expect 'daylight' to be zero, but it is 1. Thus the VM concludes that we are in a zone at offset GMT+10:00 with DST, and produces the given results. According to the Solaris man page (man tzset), the meaning of 'daylight' is: "The external variable daylight indicates whether time should reflect daylight savings time." Use of 'altzone' is no different; 'altzone' for Australia/Queensland is reported as GMT+11:00. Please close this bug as fixed (the original bug, the confusion of US and Australian EST, is fixed). If possible, it would be good to open a bug against SunOS 5.6 with the above information (this is something I cannot do). alan.liu@eng 1999-03-19 It's not a Solaris bug. On UNIX, 'daylight' reflects historical time zone information and its value is 1 if the zone used to have DST. Currently the JVM timezone initialization assumes that 'daylight' means the specified zone *currently* has DST or not, which is not a correct assumption. masayoshi.okutsu@Eng 1999-05-17
17-05-1999