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:

1. Their Java platform applications use directly the three letter time zone IDs "EST", "HST" and "MST". Sun documented a warning against doing this in 1998, explaining that since short time zone abbreviations such as "EST" are ambiguous they should not be used, and that the long names, such as "America/New_York", should be used instead. Sun has continued to support the short time zone abbreviations from the version 1.2 of the Java platform onwards, to provide compatibility with Java platform 1.1 applications that were written when the short time zone abbreviations were the only ones available. This backward compatibility support of some three-letter time zone IDs ended with the introduction of new time zone data in late 2005. The new incompatibility issue is a result of the Olson data time zone tables modifying the meaning of "EST" in the Java programming language. The new time zone tables create a new identifier "EST5EDT" to refer to the (major) part of the Eastern Time Zone area that observes DST. A similar change took place with the meaning of "MST".

   This is documented in bug report: 6466476: "(tz) Introduction of tzdata2005r can introduce incompatility issues with some JDKversion 1.1 3-letter TZ IDs".

2. The customer's Java platform applications parse time strings that contain "EDT", "HDT", "MDT". In limited circumstances, a long time zone representation stamp can be converted to the deprecated three-letter time zone IDs through internal logic contained in the JDK software's classes. In particular the java.text.SimpleDateFormat class 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 SimpleDateFormat class 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".