Java Daylight Saving Time: Known problems and workarounds

Flash (Alert)


Abstract

Known problems and workarounds for Daylight Saving Time (DST) issues related to Java SDKs, JREs, and Service Refreshes.

Content

For general information about Java and Daylight Saving Time change, see:

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



Java applications return incorrect time after using Microsoft timezone.exe tool to update Windows

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);




Use of three-character TimeZone identifiers

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.

Java6

GA
default
y
sun.timezone.ids.oldmapping=true
y
sun.timezone.ids.oldmapping=false
n


Java5

GA
SR1-SR3
SR4-SR6
SR7+
default
y
n
n
y
ibm.dst.compatibility=true
n/a
n/a
y
n/a
ibm.dst.compatibility=false
n/a
n/a
n
n/a
sun.timezone.ids.oldmapping=true
n/a
n/a
n/a
y
sun.timezone.ids.oldmapping=false
n/a
n/a
n/a
n


Java 1.4.2

GA-SR4
SR5-SR6
SR7-SR9
SR10+
default
y
n
n
y
ibm.dst.compatibility=true
n/a
n/a
y
n/a
ibm.dst.compatibility=false
n/a
n/a
n
n/a
sun.timezone.ids.oldmapping=true
n/a
n/a
n/a
y
sun.timezone.ids.oldmapping=false
n/a
n/a
n/a
n


For the IBM i Java platform, a similar workaround is available from your IBM service channel.




Change history

Date Description
5 May 2009 Updated list of known problems and workarounds
23 Apr 2009 Updated use of 3-character TimeZone identifiers
19 Aug 2007 Add New Zealand changes
28 Feb 2007 Add links back to the start page and off to the JTZU known problems
7 Feb 2007 Removed VMWARE Linux limitation
22 Jan 2007 Added information on PMR 34659, Microsoft utilities, and VMWare
28 Nov 2006 Initial publication

Related information

Download IBM Time Zone Update Utility for Java

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Runtimes for Java Technology
Java SDK

Software version:

1.4.2, 5.0, 6.0, 7.0

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows, z/OS

Reference #:

1250503

Modified date:

2009-07-20

Translate my page

Machine Translation

Content navigation