Sun Alert 102836 describes a potential vulnerability that can exist when creating and parsing time zone calculations that use old deprecated three-letter IDs for their time zone identification. The affected three-letter IDs are "EST", "HST" and "MST". The representation of these three-letter IDs changed when Olson (our data providers) tzdata2005r was released. From this Olson data release onwards these three time zone IDs moved away from the old Java Development Kit (JDK) version 1.1 time zone representation and became independent new zones. Sun included Olson's updated definitions in subsequent updates and versions of the Java platform. In particular this meant the "EST" zone no longer observed daylight savings time (DST) rules. Any Java language application that is susceptible to this incompatibility could report an erroneous time stamp, and be one hour off the expected result during the US daylight savings time period.
For a list of JDK versions that contain tzdata2005r or greater see the question Which JRE version updates include which versions of the Olson data? in the Java SE platform DST FAQ.
The impact and severity of this potential incompatibility should be viewed in perspective. Although certain customer applications might be coded in a similar way to the failing test case, this coding practice is unlikely to be widespread. Sun's recommendation is for customers to assess their applications for impact before concluding that remedial action is necessary. Customers who are still unsure if they are affected should follow "Relief/Workaround" section of the Sun Alert document.
Customers have limited exposure to this incompatibility issue. For a customer to be affected either one or both of the following conditions need to be true:
This is documented in bug report: 6466476: "(tz) Introduction of tzdata2005r can introduce incompatility issues with some JDKversion 1.1 3-letter TZ IDs".
java.text.SimpleDateFormatclass exposes the problem. This bug was only discovered recently and fixes are already under way in all affected Sun JDK update releases. The bug is limited in as much as for it to be observed, an application needs to be using the
SimpleDateFormatclass and also be performing calculations on one of the affected three-letter time zone IDs. The problem arises due to the fact that a time stamp string containing "EDT" or "MDT" is not parsed with the daylight saving offset (namely, +1 hour), therefore, it produces a wrong time value.
Note : This symptom cannot be observed with "HDT" because Hawaii does not observe DST.
This is documented in bug report 6530336: "(tz) DST bug in latest jdk releases when using EST MST and HST abbreviations".