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 ----------
Posted Date : 2007-03-10 16:41:49.0

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.

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
Posted Date : 2007-03-11 07:26:52.0

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.
Posted Date : 2007-03-11 07:34:48.0

.
Posted Date : 2007-03-11 07:35:04.0

does anyone know if this is also problem with the DST patch (e.i older JDK version 1.3.x with patch)
Please advice,
Amit 
amonovich@rsa.com

Is the applicable to the JRE 1.5.0_11 and should I be removing the EST file documented in the Work Around

Does this issue effect other vendor JVM's that are built off of Sun's implementation such as JRockit or HP?

Does this bug impact version 1.4.2_11?  I'm thinking of rolling back as a workaround.  Thanks.

Does this apply on the affected JDK's which also have the DST patch applied?

we are not parsing time in Dateformat.
We are using parse on date in Dateformat.
Is the date parsing also effected by this bug ?

Pls let us know.

Thx,
Archana

Calendar.set() shows this behavior as well (and may be the root cause).  Same repro, but use:

Calendar cal =            Calendar.getInstance(TimeZone.getTimeZone("EST"));
        cal.set(2007, 05, 06, 14, 00, 00);
Date date = cal.getTime();

There's a better description and explanation for this in the bug report for bug id 6466476.

This does seem to affect HP's JVM, not sure about JRockit. And this seems to have been introduced in the DST patches. I ran the code in this report against a JVM before and after applying the DST patches, works as expected before, exhibits the bug afterwards.

This issui do effect JRockit as well, and all the workarounds so far (both removing EST, or running tzupdater with -f -bc) will work for JRockit. You will have to use the JRockit version of tzupdater though (http://edocs.bea.com/jrockit/geninfo/diagnos/tzupdate.html)

I would like a comment from Sun about this issue. Sure, it is related to 6466476 but it's not quite the same. 6466476 is a decision by Sun to be compatible with the Olsen time zone database, but in this issue the same time-string is parsed to differ only two hours if timezones three hours apart. That has to be considered a strange behaviour even if EST no longer uses Daylight Saving Time.

Also, isn't this the way you SHOULD be using EDT after the change in behaviour for EST/EDT? Using EST to describe "winter time" and EDT to describe "summer time". Otherwise, what is the recommended way to perform the actions in the repro? I couldn't change EDT to America/New_York, but maybe that is because of the argument to the SimpleDateFormat constructor?

If you really want to create a date from East coast Summertime, what should you use instead?

Finally, if three letter time zones are deprecated, how come the output from date use them?

Its seems that this bug does not exist in JRE version v1.3.1_19. I ran the test case mention in this article with this version & it gave correct output. 

Vishal

Is running tzupdater with '-bc' a proper workaround for this?

Mark

I was able to confirm this issue with several 1.4.2 and 1.5.0 JREs.  However, jre1.5.0_06, jre1.5.0_07 do not exhibit this timezone issue.

I also reproduced the problem using MDT.

Running tzupdater -f -bc seems to have fixed the problem.  I tested it with EDT and MDT on several 1.4.2 and 1.5.0 JREs and both work now.

Does the -bc flag introduce new issues with the JREs?

Does this affect CST in any way?

Thanks.

We see this issue for jdk1.4.2_12 also. JDK1.4.2_11 looks to be fine.

Ashok 
apatil@guidewire.com

Please refer to the following link for SUN's response:

http://sunsolve.sun.com/search/document.do?assetkey=1-26-102836-1

Cheers,
Lefond

Since this is a VERY serious issue an info about the ETA of a fix would be greatly appreciated. Thx.
support@hobsoft.com

Is anyone aware if this issue impacts JRE 1.3.1.18 and older?  I see that Vishal mentioned that it did not fail with .19, but I am looking for .18 feedback.

> Does this affect CST in any way?

> Thanks.

----

doesn't seem like it (only affects Eastern and Mountain)

running the following

java -Duser.timezone=US/Hawaii Moh (jdk ver 1.4.2_13)

import java.text.*;
import java.util.*;

public class Moh {

        public static void main(String[] args) throws Exception {

		// note, HST == -10H UTC, no daylight savings

                SimpleDateFormat timestampFormatWithZone = new SimpleDateFormat("yyyy-MM-dd HH:mm zzz");

	        Date date = timestampFormatWithZone.parse("2007-06-06 06:00 EST");
                System.out.println("Eastern Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

	        date = timestampFormatWithZone.parse("2007-06-06 05:00 CDT");
                System.out.println("Central Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

	        date = timestampFormatWithZone.parse("2007-06-06 04:00 MDT");
                System.out.println("Mountain Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

                date = timestampFormatWithZone.parse("2007-06-06 03:00 PDT");
                System.out.println("Pacific Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

        }
}

only Eastern and Mountain seem to be affected. 

jdk ver 1.4.2_13

java -Duser.timezone=US/Hawaii Moh

public class Moh {

        public static void main(String[] args) throws Exception {

		// note, HST == -10H UTC, no daylight savings

                SimpleDateFormat timestampFormatWithZone = new SimpleDateFormat("yyyy-MM-dd HH:mm zzz");

	        Date date = timestampFormatWithZone.parse("2007-06-06 06:00 EDT");
                System.out.println("Eastern Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

	        date = timestampFormatWithZone.parse("2007-06-06 05:00 CDT");
                System.out.println("Central Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

	        date = timestampFormatWithZone.parse("2007-06-06 04:00 MDT");
                System.out.println("Mountain Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

                date = timestampFormatWithZone.parse("2007-06-06 03:00 PDT");
                System.out.println("Pacific Time should be 2007-06-06 00:00 in US/Hawaii == " + date);

        }
}

what is the expected date for fix of this defect jre JRE 1.4.2_13

I am running 05_11 in the central time zone and see this as an issue.  The SimpleTimeZone.inDaylightTime() method returns false today, though it should be true.

What can be done to fix the central time zone given that the rest of this bug only addresses EST, HST and MST??

just to clarify, this is how I determine that the timezone is incorrect in the central timezone

TimeZone tz = TimeZone.getDefault();
SimpleTimeZone stz = new SimpleTimeZone(tz.getRawOffset(), tz.getID());
Calendar cal = Calendar.getInstance();
System.out.println(stz.inDaylightTime(cal.getTime()));

Sorry, ignore my posts about central time.  We should have just used the TimeZone object directly and should have read the Javadocs for SimpleTimeZone constructor a little better.

Is the applicable to the JRE 1.5.0_07(b03)?