The java.util.TimeZone abstract class that represents a time zone is used to produce local time for a particular global time zone. A TimeZone comprises three basic pieces of information: an ID, a time zone offset, and the logic necessary to deal with DST (Daylight Savings Time).

While working with the TimeZone class provided with JRE 1.3 and 1.4, however, I discovered that it provides erroneous times for several time zones. This article describes this DST transition date problem, presents TimeZone test scenarios, and introduces TimeZonePatch. This patch is a flexible solution that enables the java.util.TimeZone to produce correct time zone data.

TimeZone Problem
I encountered the problem while working in a Java application that delivers Short Message Service (SMS) to wireless devices. The company's SMS application was being used in several countries and users were registering from several distinct time zones. A key requirement for the application is to have the user's local time as part of the SMS message.

The TimeZone JRE class was being used to retrieve the user's local time in the SMS message according to the user's registered time zone. It was discovered, however, that the application was delivering erroneous local times, and further investigation showed that the DST transition dates were not accurate for a number of time zones.

Testing TimeZone
The following test case was used to identify the time zone DST transition dates problem. It's based on the JUnit framework and is composed by TestTimeZone and DST classes (see Listings 1 and 2, respectively). The source code can be downloaded from www.caroli.org.

The correct DST entry and exit dates can be selected from trusted sources. For this article the dates were selected from the world clock Web site: www.timeanddate.com/worldclock/full.html.

To verify the DST transition problem the TestTimeZone test case was executed for two distinct time zones: America/Sao_Paulo and America/Santiago. The time zone data in the DST classes was retrieved from the world clock Web site.The tests results are depicted in Figures 1 and 2. Note that these tests are based on the JDK TimeZone class usage.

TimeZone Test 1:
America/Santiago time zone

public class DST{
  public static final String DATE_FORMAT = "MM/dd/yyyy";
  public static final String START_DST = "10/10/2004";
  public static final String END_DST = "03/14/2004";
  public static final String TIMEZONE_LOCATION = "America/Santiago";
}

TimeZone Test 2:
America/Sao_Paulo time zone

public class DST{
  public static final  String DATE_FORMAT = "MM/dd/yyyy";
  public static final  String START_DST = "11/02/2004";
  public static final  String END_DST  = "02/15/2005";
  public static final  String TIMEZONE_LOCATION  = "America/Sao_Paulo";
}

Test 2 for TimeZone shows the inaccuracy in the DST entry date of the TimeZone class with the America/Sao_Paulo time zone.

Patching TimeZone
The tests were executed with JRE 1.3 and 1.4 and both showed the same problem. Both versions of the TimeZone class read time zone IDs from the the tzmappings file in the jre/lib subdirectory. JRE 1.4 also contains time zone data files for various world regions in the jre/lib/zi subdirectory.

One solution for the 1.4 TimeZone class is to update the time zone files; however, these are binary and its change is dependent on you having access to and intimate knowledge of the JRE. The JRE provider could supply updates to the time zone files, however, it's not straightforward even for them to keep track of all the time zones' correct data. Although there are conventions about the DST transition dates and times, countries have the freedom to decide their own transition dates and times, and this has occurred in several places.

For these reasons I developed a patch for the SDK TimeZone, which solves the wrong DST transition dates problem independent of the original TimeZone implementation.

TimeZone Test Set-Up

public class TestTimeZone extends TestCase {
.
    protected void setUp() throws Exception {
//        timeZone = TimeZonePatch.getTimeZone(DST.TIMEZONE_LOCATION);
        timeZone = TimeZone.getTimeZone(DST.TIMEZONE_LOCATION);
        super.setUp();
    }
.
}

TimeZonePatch
The TimeZonePatch class has been created for patching time zones according to an elected time zone data source. Listing 3 shows the TimeZonePatch code.

The fix works by having the TimeZonePatch class return your desired version of TimeZone. In case there is a time zone correction, this correction will be set in the timezonePatchList, which holds the patched TimeZone's objects. The TimeZonePatchListFactory class builds timezonePatchList.

A Factory of Your Time Zone Data
TimeZonePatchListFactory can get the time zone data from different sources. For example, the time zone data source can be an XML file, text file, database, Web service, or any other data source appropriate for your application.

Listing 4 shows TimeZonePatchListFactory, a Factory Method implementation that creates a time zone patch list based on an XML time zone data source. (Listings 4-6 can be downloaded from www.sys-con.com/java/sourcec.cfm.)

Listing 5 has timezonePatch.xml, an XML data source read by TimeZonePatchListFactory for patching the America/Sao_Paulo time zone.

The presented TimeZonePatchListFactory implementation uses JOX (Java Objects in XML) library for reading the XML file into the TimeZonePatchList JavaBean.

When reading the XML document, a mapping between the root node name - TimezonePatchList - and the nested nodes - timezonePatch, dst, startDate, and endDate - is automatically made for the TimeZonePatchList bean, and the nested beans - TimeZonePatch, DST, and Date - respectively.