Timezone value changes per JDK version

Question

When I have compiled and runned following code statement at the same machine, I am getting two different timezone values.

public class TimeZoneDemo {
   public static void main( String args[] ){

  // create time zone object     
  TimeZone timezone = TimeZone.getDefault();

  // checking time zone value     
  System.out.println(timezone);
   }    
}

JDK 1.6.35

Tue Sep 24 06:25:03 VET 2013
sun.util.calendar.ZoneInfo[id="America/Caracas",offset=-16200000,dstSavings=0,useDaylight=false,transitions=5,lastRule=null]

JDK 1.7.02

Tue Sep 24 22:56:54 MAGT 2013
sun.util.calendar.ZoneInfo[id="Asia/Magadan",offset=43200000,dstSavings=0,useDaylight=false,transitions=66,lastRule=null]

OS: Window 7 64 Bit.

Answer 1

The timezone is set against the JVM not the JDK. You set this against the jvm with...

Duser.timezone="Europe/Sofia"

If you pass this to the JVM you'll always have the same timezone when you change versions.

The oracle documentation on TimeZone.getDefault() mentions...

Gets the default TimeZone for this host. The source of the default TimeZone may vary with implementation.

Answer 2

When you look at the following table you will see what updates have been done to the JRE version.

http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html

The version 1.6.35 is newer than the version 1.7.02. However, it is still possible that one of these environments has been updated with the TZUpdater.

Since only you know where your computer is located only you know whether there is a relevent change.

Answer 3

我发现了类似的问题， java的时区不正确如我所料，该问题存在错误，并且已经使用当前版本的JDK解决了

Answer 4

These problems come and go, and no reasonable solution. See more here: Java incorrect time zone bug on Windows

Edit: Answering Andrew Arnold: In brief, Java runtime has hard time doing the job of correctly finding out the current time zone on the computer.

Windows registry information on the time zones has been unreliable, and the same for native windows API which relies on msvcrt.dll and various msvcrxx.dll . There is also Managed (.NET) API which requires installing a certain version of .NET Framework which contradicts portability of Java.

Thus, developers of Java runtime have hard time with the current time zone on Windows, and this may continue until Microsoft has some reason to cooperate.