EVALUATION

.
                                     

EVALUATION

Here's the detailed information.

There's a time zone display name table in the ResourceBundle format per locale. The table (for the root locale) looks like this:

 { "America/Los_Angeles", new String[] { "Pacific Standard Time", "PST", "Pacific Daylight Time", "PDT" }}
  ...

The first string is a time zone ID which is a key, and the string array is its value consisting of display names of the time zone. SimpleDateFormat.parse() looks up entries of this kind from the top to the bottom. If the given date string has "PDT", it matches the 3rd element of the string array, and parse() thinks the given date is under the "America/Los_Angeles" time zone. When calculating the time value, parse() gets the time zone offset values calling TimeZone.getRawOffset() for the GMT offset and TimeZone.getDSTSavings() for the time zone's DST amount (usually one hour).

Now, the Eastern time has the following in the time zone display name table.

  ...
 { "EST", new String[] { "Eastern Standard Time", "EST", "Eastern Daylight Time", "EDT" }}
 { "America/New_York", new String[] { "Eastern Standard Time", "EST", "Eastern Daylight Time", "EDT" }}
  ...

If the given date string contains "EDT", parse() will pick up time zone ID "EST". In tzdata2005r or later, time zone EST doesn't observe DST at all and its getDSTSavings() always returns 0. The fix was to change the order of the "EST" and "America/New_York" entries so that "America/New_York" is picked up before "EST".

Removing jre/lib/zi/EST enables the EST to America/New_York mapping. The same problem happens with the MST time zone. HST has been added in tzdata2005r as well, but Pacific/Honolulu doesn't observe DST since 1946. So HST doesn't have this problem (unless very old time stamps are concerned).

1.3.1 and ealier releases don't have this problem.
                                     

EVALUATION

This bug is one of two bugs documented in the Sun Alert 102836. Refer to the Sun Alert document for more info: http://sunsolve.sun.com/search/document.do?assetkey=1-26-102836-1

The effect of this bug is limited to the parsing of date strings containing one of the following time zone names:

    * "EDT" or "Eastern Daylight Time"
    * "MDT" or "Mountain Daylight Time"
    * "HDT" or "Hawaiian Daylight Time"

Furthermore, because Hawaii does not generally observe daylight savings time, this bug is limited to parsing Hawaiian dates prior to 1947.

Parsing strings containing "EDT" or "Eastern Daylight Time" when the application's default time zone is set to "America/New_York" is not affected.  Likewise, parsing strings containing "MDT" or "Mountain Daylight Time" when the application's default time zone is set to "America/Denver" is not affected.  "America/New_York" and "America/Denver" are automatically set as the default time zones for most machines located in those time zones.

This bug is present only in JDKs that contain Olson time zone data version 2005r or greater.  This translates to:

    * JDK/JRE 1.4.2_12 and above
    * JDK/JRE 5.0u8 and above
    * JDK/JRE 6 and above
    * Any 1.4 or above JDK/JRE which has been updated via the tzupdater tool
                                     

WORK AROUND

There are two work arounds.

1. Apply the tzupdater tool with the -bc (backward compatibility) flag. If the tool has not been previously run this will update your installation to the latest available time zone data but will not add data for the EST, MST and HST IDs.  If the tool has been previously run or your time zone data is already up to date you can run the tool with the -f (force) and -bc flags.  This causes the data for the EST, MST and HST IDs to be removed from your installation.  For more details on the tzupdater tool, please refer to http://java.sun.com/javase/tzupdater_README.html.

2. Manually remove the three time zone data files, EST, MST, and HST in the <JDK_HOME>/jre/lib/zi directory (or <JRE_HOME>/lib/zi). 

Both workarounds have the effect of removing the data files for EST, MST and HST.  When the system can't find the data files for EST, MST or HST it will fall back to using America/New_York for EST, America/Denver for MST, and Pacific/Honolulu for HST.  These alternates observe daylight savings time and are thus compatible with the JDK's traditional behavior.

Note that by applying the above workarounds you choose compatibility with the JDK's traditional behavior over compatibility with the Olson time zone standard for the EST, MST and HST time zone IDs.  Because the Olson definition for these three IDs is fairly recent (late 2005) and the availability of this data in a Java SE release is even more recent (mid 2006) Sun expects few current applications will require strict Olson compatibility.