Sun Java SE TZupdater tool

Introduction · System Requirements · Installation · Usage · Error Handling · Known Restrictions

Introduction

The tzupdater tool is provided to allow the updating of installed JDK/JRE images with more recent timezone data in order to accomodate the U.S. 2007 daylight saving time changes (US2007DST) originating with the U.S. Energy Policy Act of 2005.
While Sun recommends utilizing the latest Sun Java SE JDK/JRE update release as the preferred vehicle for delivering both timezone data updates and other product improvements such as security fixes; if the end-user or system-administrator is unable to use the latest Sun JDK/JRE update release, this tool provides a route of updating timezone data while leaving other system configuration and dependencies unchanged.
The 1.0 version delivers Olson data tz2006n which has also been included in the following Sun Java SE JDK/JRE releases: 6, 5.0_11, 1.4.2_14, 1.3.1_20.
For more complete background information please visit the page http://java.sun.com/developer/technicalArticles/Intl/USDST/

System Requirements

The tool supports Sun's JDK/JRE releases 1.4 or later, and on all supported platforms. The java.vendor property value must be "Sun Microsystems Inc.".

Installation

Download the tool bundle archive tzupdater-tzdata2006n-b01.zip from the Sun Java SE download site.

Usage

The command line interface is as follows.

Synopsis

    java -jar tzupdater.jar options

Options

If no options are specified, the usage message is displayed. To perform time zone data update, either the -u or -f option must be specified.

-h, --help Print the usage to stdout and exit. Other options are ignored if specified.
-V, --version Show the tool version number and the tzdata version numbers of the JRE and the archive embedded in the jar file and exit.
-u, --update Update the time zone data. If this option is specified with -h, -t or -V option, the command displays the usage to stdout and exit.
-f, --force Force update the tzdata even the version of the tzdata archive is older then the JRE's tzdata version. This option doesn't require the -u option to perform the update.
-v, --verbose Display detailed messages to stdout.

-bc, --backwardcompatible

 Keep backward compatibility with the 3-letter time zone IDs of JDK 1.1. Any time zone IDs that conflict with the JDK 1.1 time zone IDs will be removed from the installed time zone data. See the known restriction section for details. This option must be specified with the -u, -f or -t option.
-t, --test Runs verification tests only and exit. The -f option is ignored if specified. If the -bc option is specified, any test cases for time zone IDs that conflict with the JDK 1.1 time zone IDs will be ignored.

Error Handling

The tool tries to restore the original state when it has encountered an unexpected error, such as lack of disk space. Such errors will generate a TzRuntimeException.

Known Restrictions

The tool has a few restrictions due to the TimeZone API and implementation constraints.

  1. Time zone display names
    This tool will not update time zone display names of time zones that are completely new or have display name related changes. An example is that Europe/Podgorica is a new time zone ID in tzdata2006n due to the Serbia/Montenegro split. Another example is that America/Indiana/Knox changed from Eastern Time to Central Time on April 2, 2006, which change appeared since tzdata2006a. The time zone display names for America/Indiana/Knox were changed in 1.5.0_08.
  2. JDK 1.1 time zone ID compatibility
    In tzdata2005r, the Olson time zone database added EST, MST, and HST with no DST rules (i.e., standard time only). These IDs conflict with the same IDs in JDK 1.1. When users need the JDK 1.1 compatible time zone IDs rather than the complete set of the Olson time zone IDs, these incompatible IDs need to be removed. See also Sun's bug 6466476.
  3. TimeZone.getAvailableIds(int) and TimeZone.getRawOffset() limitation and JCK
    These TimeZone methods don't take a time stamp based on the API design assumption that a time zone's GMT offset never changes. Therefore, it's not possible to keep their return values consistent all the time. There's JCK test case TimeZone2014 that the return values of these methods are consistent. This test case fails if and only if there are any time zones of which GMT offsets will change in future time. A workaround fix was added to 1.5.0_4 and 1.6.0, which involved a time zone data file format change. Therefore, two versions of time zone data archives need to be provided with the tool in case that a future GMT offset change is involved in any time zones. See Sun's bug 5055567 for details. Note that the JCK test case fails without the 5055567 fix until the actual GMT offsets transition occurs.