Pre-General Availability: 2017-05-23

8 Time Zone Settings in the JRE

This chapter describes some issues that can arise with time zone settings with the Java Runtime Environment (JRE) on the Windows operating system. Further describes troubleshooting techniques and workarounds to solve these issues.

This chapter contains the following sections:

Native Time Zone Information and the JRE

The JRE reads the native time zone information to determine your default time zone.

For example, on Windows, the JRE queries the registry to determine the default time zone.

However, the JRE also maintains its own time zone database. This provides cross-platform support because the different operating system APIs are not sufficient to support the Java APIs. The Java time zone database supports time zone IDs and determines daylight saving time rules for all the time zones that the JRE supports. The tzupdater tool is available for download from the Java SE Download Page.

Modifications to the JRE for each specific operating system are necessary so that the operating system can deliver the system time to the JRE. Then, if a Java application requests the system date by calling date and time related constructors, the system time is returned.

Examples of such constructors are:

  • java.util.Date()
  • java.util.GregorianCalendar()

Constructors related to date and time include:

  • System.currentTimeMillis()
  • System.nanoTime()

Operating system-specific patches might be required to ensure that the correct system time is delivered to the JRE.

The following sections describe troubleshooting techniques for time zone settings.

Determine the Time Zone Data Version in Use

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 has been 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 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 a typical result of such a 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
    

Troubleshoot Problems with TZupdater

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 -Vtzupdater version 1.3.39-b01JRE time zone data version: tzdata2009iThere'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 attempting to run 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 -u
java.home: /opt/java6/jre
java.vendor: Hewlett-Packard Co.
java.version: 1.6.0.05
JRE time zone data version: tzdata2009i
There's no tzdata available for this Java runtime.

In the above 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 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 tzupdater tool.

Determine the Default Time Zone on Windows

This section clarifies how the JRE determines the default time zone on the Windows Vista and Windows 7 operating systems. If Java doesn't report the expected time zone, use the troubleshooting techniques provided in the following sections:

Check the Default Time Zone JRE Reports

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 above 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 above 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.

Determine the Setting in the Control Panel

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."

Check for Automatic Daylight Saving Time Adjustment

You can check whether 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, follow these steps.

    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 click box labeled “Automatically adjust time for Daylight Savings Time." Observe whether or not this click box is clicked, and change the setting if you desire.

    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 examining or editing it. If you make a mistake in editing, you can damage the Windows registry.

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

    1. Click the Windows Start button.

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

    3. In the Registry Editor, search for the key DynamicDaylightTimeDisabled and examine 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 have disabled the DynamicDaylightTimeDisabled option, then Java always 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."

Set the Default Time Zone in the Control Panel

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

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

  1. Click the Windows Start button and then click Control Panel.
  2. Click Date and Time.
  3. Click the Change Time Zone button.
  4. From the Time Zone menu, select your preferred time zone.
  5. Click OK. This returns you to the Date and Time dialog box.
  6. Click OK to close the Date and Time dialog box.

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."

Check -Duser.timezone System Property

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 in some cases. For instance, this setting is useful if you want DST (daylight saving time) only for a single Java program running on the system.

The following example examines 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)

Special Tools in Windows 7

With Windows 7, a tool called tzutil.exe is available. With this tool, you can request the current time zone ID abbreviation without manually reading the registry.

Here is an example of running tzutil.exe. The first line is the command that you enter in Windows Command Prompt window. The second line is the system response.

tzutil /g

W. Europe Standard Time

JRE Internal Representation of Time Zone Mappings

On Windows, the JRE uses a file <java-home>\lib\tzmappings to represent the mapping between Windows and Java time zones. Each line in the file has four tokens. The first token is the Windows time zone registry key called TimeZoneKeyName. See Determine the Setting in the Control Panel.

The second token is a time zone map ID. (This is not used in Windows Vista and Windows 7.) The third token is the locale. The fourth token represents the Java time zone ID. The important tokens are token number one, number three (which can be empty), and number four. (Note: This file is not a public interface.)

If you select the time zone called “(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna" in the Windows Control Panel, then the relevant line in the file tzmappings is:

W. Europe Standard Time:2,3::Europe/Berlin:

In this example, the JRE recognizes your default time zone (token number four) as “Europe/Berlin."

If there is no appropriate mapping entry in the tzmappings file, then it is possible that Microsoft introduced a new time zone in a Windows update, and that the new time zone is not available to the JRE. In this situation, you can file a bug report for the JRE and request a new entry in the tzmappings file from Oracle Java bugs website.

A similar disconnect between the operating system and the JRE is possible if you have run the tool tzedit.exe. This tool is posted by Microsoft on the Internet, and allows users to add new time zones. The JRE is unlikely to have a time zone introduced into the system by this tool. Again, the solution is to file a bug to request that a new entry be added to the tzmappings file.