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.

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

Note: IBM SDK, Java 2 Technology Edition, Version 5.0 is no longer supported unless you have an extended support contract with IBM.

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