Flashes (Alerts)
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 |
Note: IBM SDK, Java Technology Edition, Version 6 and 5.0 are 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.
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
Was this topic helpful?
Document Information
Modified date:
25 September 2022
UID
swg21250503