Java Daylight Saving Time: Known problems and workarounds

Guidance on updating Java SDKs and JREs for Daylight Saving Time (DST) changes

This document contains general Java Daylight Saving Time known problems. For information regarding JTZU, see:

IBM Time Zone Update Utility (JTZU): known problems and diagnostic information

	Java Applications return incorrect time after using Microsoft timezone.exe tool to update Windows
	Use of three-character TimeZone identifiers

Problem symptoms
After using the Microsoft timezone.exe tool to update Windows, the operating system time and date information passed by Windows to Java is incorrect. This causes Java applications to fail, returning a time of GMT instead of the required local time.

Problem explanation
Microsoft has made available two separate tools for customers to update their Operating Systems for the North America DST 2007 changes. The first is called TZEdit.exe and the second is called timezone.exe. The tool timezone.exe does not modify certain Windows Registry settings in a consistent way, which causes the Java time and date calculations to malfunction and incorrectly return a time of GMT by default.

Resolution
In situations where the formal patch update, or Hotfix, from Windows cannot be applied, use TZEdit.exe in preference to timezone.exe. If you have already run the timezone.exe tool, your system will not be correctly updated. To correct this, follow the recommended procedure using TZEdit.exe.

Test Case
Run the following test case as a Java program to confirm that the Operating System has been correctly modified. Today's date is displayed, with a time zone that matches the Windows setting.

import java.util.Date;
import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.TimeZone;

public class DateTest {
    public static void main(String[] args) {
        GregorianCalendar cal = new GregorianCalendar();
        Date today = cal.getTime();
        System.out.println("today: " + today);

Reference:
PMR 31047,005,000
APAR PK30359

Problem symptom

In applications that have a time zone identifier of "EST" or "MST" coded as a parameter of the TimeZone Java class in the application program or in the user.timezone system property, the time returned by the API call is one hour different than expected.

Problem explanation

In 2006, the meaning of the EST time zone identifier changed in the Olson database. Historically, EST referred to the American Eastern Standard Time and made adjustments for daylight saving time. Following the change, EST refers to Eastern Standard Time with no adjustment for daylight saving time. A new identifier EST5EDT was also introduced that had the same meaning as the original EST identifier. EST5EDT therefore refers to the American Eastern Standard Time and makes adjustments for daylight saving time.

Similar changes were made to the Olson database for the time zone identifier MST.

Java applications running on more recent Java service refreshes (SR) that use a time zone identifier of EST or MST work as before, because these Java SRs continue to use the old meanings. However, there are some intermediate levels of Java where EST or MST has the new meaning and does not adjust for daylight saving time.

Resolution

The best way to avoid these problems is to use long time zone identifiers like America/New_York.

If you cannot change an application to use the long time zone identifiers, you can set the system property ibm.dst.compatibility or sun.timezone.ids.oldmapping to alter the interpretation of EST or MST.

The tables show which system property can be used for a particular Java SR to determine the behavior of the EST or MST time zone identifier. The letter y indicates that there will be an adjustment for daylight saving time.