JDK-6530336 : (tz) DST bug in latest jdk releases when using EST MST and HST abbreviations
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.4.2_13,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris,solaris_10
  • CPU: generic,sparc
  • Submitted: 2007-03-02
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
1.4.2_14Fixed 6u1Fixed 7 b14Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
All current versions (1.4.2_13, 1.5.0_11, 1.6)

ADDITIONAL OS VERSION INFORMATION :
Anything

CUSTOMER DESCRIPTION OF THE PROBLEM :
"The recent change to the definition of EST timezone to remove DST awareness has broken basic functionality in date handling.

The problem is very simple. The DateFormat parser uses the contents of String zoneStrings[][] in class DateFormatSymbols to identify the timezone based on the zone value in the input date string.

The zoneStrings[][] array defines "EST" before "America/New_York" so sets the timezone for the parser to the now non-DST aware "EST" zone."

The customer feels this is a serious issue.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the test code below as shown.
First run as java -Duser.timezone=America/New_York Moh

and the output is correct: Wed Jun 06 14:00:00 EDT 2007

Then run as java -Duser.timezone=America/Los_Angeles Moh

and the output is wrong: Wed Jun 06 12:00:00 PDT 2007

The correct output would be 11:00:00 PDT 2007.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In the test case when in the Los Angeles time zone I expect the time to be 11:00:00 PDT but it wrongly displays 12:00:00 PDT.
ACTUAL -
As above.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.*;
import java.util.*;

public class Moh {
        public static void main(String[] args) throws Exception {
                SimpleDateFormat timestampFormatWithZone = new SimpleDateFormat("yyyy-MM-dd HH:mm zzz");
                Date date = timestampFormatWithZone.parse("2007-06-06 14:00 EDT");
                // Calendar calendar = timestampFormatWithZone.getCalendar();
                System.out.println(date);
        }
}

---------- END SOURCE ----------

Comments
EVALUATION .
10-03-2007

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.
09-03-2007

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
06-03-2007

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.
02-03-2007