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