JDK-4064913 : TimeZone.getDefault() always returns GMT as current timezone
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1997-07-16
  • Updated: 1997-10-23
  • Resolved: 1997-10-23
Related Reports
Duplicate :  
JDK-4069784 - TimeZone.getDefault() returns incorrect time zome.
Relates :  
JDK-4031021 - Calendar.getTime() does not return localized date and time. It always returns GM
Description
From: Bjoern-Arne Meyn <###@###.###>

On my computer running under Windows 95, the default timezone is MET (Middle European Time = GMT + 1 / +2 DST).  Java code such as the following should return MET as default timzone and a raw offset of 1 (* 60 * 60 * 1000).

SimpleTimeZone stz = (SimpleTimeZone)SimpleTimeZone                       		    .getDefault();
System.out.println(stz.getID());
System.out.println(stz.getRawOffset() / (60 * 60 * 1000));

The values returned by the code are GMT and 0, no matter what the actual timezone is. If I change the timezone in my system's configuration, to EST for example, Java fails to notice this and still returns the values above.
Comments
EVALUATION Apparently, the system initialization code only recognizes a subset of the time zones that Java can handle. According to Alan Liu (Taligent), "the zone containing Paris is detected. The zones containing Berlin and Prague are not detected". Since at least Berlin and Paris always have the same time, they should be treated the same (I don't know whether Czechia follows EU rules for DST). Yvonne Tso also reported a similar problem on Solaris: Here "Hongkong" as the value of TZ isn't recognized; it should be mapped to Java's CTT zone. And a related problem: the fallback on Solaris is PST, as opposed to GMT on Windows. Obviously GMT is the better fallback. norbert.lindenberg@Eng 1997-07-22 --------------------------------------------------------------------------------
22-07-1997