8 Time Zone Settings in the JRE

The time zone database version that ships in any JRE from Oracle is documented in the release notes. However, the actual version can be different from the version mentioned there if the JRE was patched using the tzupdater tool.

To determine the current time zone data version of your JRE, either run the tzupdater tool with the Version option, or examine the header of the ZoneInfoMappings file.

Follow these two steps to determine the time zone data:

• Determine the Time Zone with TZupdater: The Java time zone updater tool is called tzupdater. To determine the time zone database version of your JRE, run this tool as follows:

  java -jar tzupdater.jar -V
  

  Here is a typical output from running the tzupdater tool.

  tzupdater version 2.1.0-b04
  JRE tzdata version: tzdata2016f
  

  You can download the tzupdater tool from this web page: Timezone Updater Tool.

• Examine the ZoneInfoMappings File: Even without the tzupdater tool, you can quickly check the version by examining the header of the file <java-home>/lib/zi/ZoneInfoMappings. This data is stored in a binary format that is specific to Java. On the Oracle Solaris, Linux and Mac macOS operating systems, you can use the octal dump command to see the header of this file.

  The following example shows the octal dump command format.

  /usr/bin/od -c -j 11 -N 11 <java-home>/lib/zi/ZoneInfoMappings
  

  The following example shows the typical result of the dump command.

  /usr/bin/od -c -j 11 -N 11 /farfaraway/jdks/jdk1.6.0_21/jre/lib/zi/ZoneInfoMappings0000000   t   z   d   a   t   a   2   0   1   0   i0000013
  

  The following example shows the time zone data version that is embedded in that JRE is tzdata2010i.

  On Microsoft Windows, you can use the findstr command to examine the ZoneInfoMappings file. Here is an example.

  findstr tzdata <java-home>\lib\zi\ZoneInfoMappings
  

Sometimes, when you run tzupdater, it quits with the message: “There's no tzdata available for this Java runtime." The following are two examples.

$ java -jar tzupdater.jar -V 
tzupdater version 2.1.1-b01 
JRE tzdata version: tzdata2017b
There's no tzdata available for this Java runtime.

The likely cause is that you are using a JRE that is not from Oracle. Oracle provides the JRE for Oracle Solaris (x86, x64, SPARC), Linux (x86, x64, ARM), Microsoft Windows (x86, x64), and macOS (x64). The java.vendor property value for these is Sun Microsystems Inc., Oracle Corporation or BEA Systems, Inc. Oracle does not provide the JRE for other platforms.

The output of running the java -version command does not provide enough information to determine the actual vendor of a JRE. However, running tzupdater in update mode with the -v option does print out the java.vendor property. The following example shows the result of running tzupdater when the environment is HP_UX from Hewlett Packard.

root@my_server:/opt/java6/bin> uname -a
HP-UX my_server B.11.23 U ia64 1114591084 unlimited-user license
root@my_server:/opt/java6/bin> ./java -version
java version "1.6.0.05"
Java(TM) SE Runtime Environment (build 1.6.0.05-jinteg_14_oct_2009_01_44-b00)
Java HotSpot(TM) Server VM (build 14.2-b01-jre1.6.0.05-rc5, mixed mode)
root@my_server:/opt/java6/bin> ./java -jar tzupdater.jar -v -l
java.home: /opt/java6/jre
java.vendor: Hewlett-Packard Co.
java.version: 1.6.0.05
JRE tzdata version: tzdata2009i
There's no tzdata available for this Java runtime.

In the previous example, java.vendor is set to “Hewlett-Packard Co." The JRE that you are trying to update using tzupdater is not supported by Oracle.

A possible solution is to visit the website of your JRE vendor and determine whether a time zone updater tool is available. For example, see the Hewlett-Packard version of the tzupdater tool.

You can write a simple program to determine which time zone the JRE reports as the default time zone-based on a check with the native operating system.

The Java program in the following example returns the default time zone:

public class DefaultTimeZone {
    public static void main(String[] args) {
        System.out.println(java.util.TimeZone.getDefault().getID());
    }
}

You can save the code snippet in the previous example to a file named DefaultTimeZone.java and compile it using the javac command. Then, you can run the compiled DefaultTimeZone class, as shown in the following example.

c:\tztest> javac DefaultTimeZone.java
c:\tztest> java DefaultTimeZone
Europe/Berlin

In the previous example, the default time zone is Europe/Berlin. Running the program should display your local time zone. If the output is not the expected time zone, then continue with the following troubleshooting steps.

You can change or examine the system's default time zone using the Windows Control Panel. For example, you can select this time zone setting in Windows 7:

(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

The corresponding value for the Registry key TimeZoneKeyName is “W. Europe Standard Time."

You can check whether the automatic adjustment of daylight saving time is enabled through the graphical user interface (GUI) or through the Windows registry.

• GUI Method: To use the Control Panel to check whether automatic adjustment of daylight saving time is enabled:.

  1. Click the Windows Start button and then click Control Panel.

  2. Click Date and Time.

  3. Click the Change Time Zone button.

  4. There is a check box labeled “Automatically adjust time for Daylight Savings Time. “See if this check box is selected, and change the setting if you want.

  5. Click OK. This returns you to the Date and Time dialog box.

• Windows Registry Method: You can run Windows Registry Editor to check whether automatic adjustment of daylight saving time is enabled.

  Note:

  It is a good practice to back up the Windows registry before reviewing or editing it. If you make a mistake, you can damage the Windows registry.

  To enable the automatic adjustment of daylight saving time from the Windows registry:

  1. Click the Windows Start button.

  2. In the Search programs and files field, enterregedit and then press Enter to open the Registry Editor.

  3. In the Registry Editor, search for the key DynamicDaylightTimeDisabled and look at the setting.

     If the registry setting is 1, then dynamic daylight time is disabled.

     If the registry setting is 0, then dynamic daylight time is enabled.

  If you prefer, you can access the Windows registry from the Windows command window.

In the following example, the registry setting is 1. With this setting, the clock is not automatically adjusted for daylight saving time.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"DynamicDaylightTimeDisabled"=dword:00000001

If you disable the DynamicDaylightTimeDisabled option, then Java returns a GMT (Greenwich Mean Time) offset and not a time zone ID that is compatible with the uniform naming convention (such as “Europe/Berlin"). For example, the offset will be expressed as GMT+01 and not “Europe/Berlin."

You can change or review the system's default time zone by using the Windows Control Panel.

To set the system's default time zone from the Control Panel:

For example, you can select this time zone in Windows 7:

(UTC)+1:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna.

The corresponding value for the Registry key TimeZoneKeyName is “W. Europe Standard Time."

You can explicitly set a default time zone on the command line by using the Java system property called user.timezone. This bypasses the settings in the Windows operating system and can be a workaround. For instance, this setting is useful if you want daylight saving time (DST) only for a single Java program running on the system.

The following example shows the system property -Duser.timezone by running a Java program called DefaultTimeTestZone from the Windows Command Prompt window.

c:\tztest> java -Duser.timezone=America/New_York DefaultTimeZone America/New_York

If setting a default time zone explicitly by specifying -Duser.timezone works for the DefaultTimeTestZone program, but does not work for your program, you should check whether your code overwrites the default Java time zone during runtime with a method call such as this:

TimeZone.setDefault(TimeZone zone)