FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode, sharing)

and

java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b86)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b86, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Update 08 changed the interpretation of "EST" to not include DST.

This means that all legacy Applets and applications which used EST before are now broken.

See the outputs from the demo program. Eastern and EST should be the same under all Java versions.
************************
Time Zone Test on JVM 1.5.0_06
Current time in EST  = 8/31/06 9:42 PM
Correct Eastern time = 8/31/06 9:42 PM
Current time in PST  = 8/31/06 6:42 PM
Correct Pacific time = 8/31/06 6:42 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=EST,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
**********************************
Time Zone Test on JVM 1.5.0_08
Current time in EST  = 8/31/06 8:42 PM
Correct Eastern time = 8/31/06 9:42 PM
Current time in PST  = 8/31/06 6:42 PM
Correct Pacific time = 8/31/06 6:42 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
*********************************
Time Zone Test on JVM 1.6.0-beta2
Current time in EST  = 8/31/06 8:43 PM
Correct Eastern time = 8/31/06 9:43 PM
Current time in PST  = 8/31/06 6:43 PM
Correct Pacific time = 8/31/06 6:43 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the following code under different versions of Java and see the results.

Run under 1.5.0_06
Run under 1.5.0_08
Run under 1.6 beta 2

public class TimeUtil {
	
	private static TimeZone PACIFIC = null;
	private static TimeZone EASTERN = null;
	
	/**
	 * Getting eastern daylight savings time in a way that returns a valid time zone for JDK 1.1 and
	 * all later versions.
	 * @return Eastern time
	 */
	public static TimeZone getEastern() {
		if (EASTERN == null) {
			EASTERN = chooseTimeZone(new String[] { "America/New_York", "EST5EDT", "EST" });
		}
		return EASTERN;
	}
	
	/**
	 * Getting pacific daylight savings time in a way that returns a valid time zone for JDK 1.1 and
	 * all later versions.
	 * @return Pacific time
	 */
	public static TimeZone getPacific() {
		if (PACIFIC == null) {
			PACIFIC = chooseTimeZone(new String[] { "America/Los_Angeles", "PST8PDT", "PST" });
		}
		return PACIFIC;
	}

	private static TimeZone chooseTimeZone(String[] preferredChoices) {
		boolean[] availableChoices = new boolean[preferredChoices.length];
		for (int i = 0; i < availableChoices.length; i++) {
			availableChoices[i] = false;
		}
		String[] tz = TimeZone.getAvailableIDs();
		for (int i = 0; i < tz.length; i++) {
			String zoneName = tz[i];
			//System.out.println("checking: "+zoneName);
			for (int j = 0; j < preferredChoices.length; j++) {
				if (zoneName.equals(preferredChoices[j])) {
					availableChoices[j] = true;
				}
			}
		}
		for (int i = 0; i < availableChoices.length; i++) {
			if (availableChoices[i]) {
				//System.out.println("Using "+preferredChoices[i]);
				return TimeZone.getTimeZone(preferredChoices[i]);
			}
		}
		return null;
	}
	
	/**/
	// Test the time zones on current VM
	public static void main(String[] args) {
		System.out.println("Time Zone Test on JVM "+ System.getProperty("java.version"));
		DateFormat fmt = new SimpleDateFormat();
		
		Date date = new Date();
		fmt.setTimeZone(TimeZone.getTimeZone("EST"));
		System.out.println("Current time in EST  = "+fmt.format(date));
		fmt.setTimeZone(getEastern());
		System.out.println("Correct Eastern time = "+fmt.format(date));
		
		fmt.setTimeZone(TimeZone.getTimeZone("PST"));
		System.out.println("Current time in PST  = "+fmt.format(date));
		fmt.setTimeZone(getPacific());
		System.out.println("Correct Pacific time = "+fmt.format(date));
		
		System.out.println("EST = "+TimeZone.getTimeZone("EST"));
		System.out.println("PST = "+TimeZone.getTimeZone("PST"));
	}
	/**/
	
}

Outputs:
************************
Time Zone Test on JVM 1.5.0_06
Current time in EST  = 8/31/06 9:42 PM
Correct Eastern time = 8/31/06 9:42 PM
Current time in PST  = 8/31/06 6:42 PM
Correct Pacific time = 8/31/06 6:42 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=EST,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
**********************************
Time Zone Test on JVM 1.5.0_08
Current time in EST  = 8/31/06 8:42 PM
Correct Eastern time = 8/31/06 9:42 PM
Current time in PST  = 8/31/06 6:42 PM
Correct Pacific time = 8/31/06 6:42 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
*********************************
Time Zone Test on JVM 1.6.0-beta2
Current time in EST  = 8/31/06 8:43 PM
Correct Eastern time = 8/31/06 9:43 PM
Current time in PST  = 8/31/06 6:43 PM
Correct Pacific time = 8/31/06 6:43 PM
EST = sun.util.calendar.ZoneInfo[id="EST",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
PST = sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected:

EST and Eastern time are always the same
ACTUAL -
EST is one hour offset from Eastern time

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class TimeUtil {
	
	private static TimeZone PACIFIC = null;
	private static TimeZone EASTERN = null;
	
	/**
	 * Getting eastern daylight savings time in a way that returns a valid time zone for JDK 1.1 and
	 * all later versions.
	 * @return Eastern time
	 */
	public static TimeZone getEastern() {
		if (EASTERN == null) {
			EASTERN = chooseTimeZone(new String[] { "America/New_York", "EST5EDT", "EST" });
		}
		return EASTERN;
	}
	
	/**
	 * Getting pacific daylight savings time in a way that returns a valid time zone for JDK 1.1 and
	 * all later versions.
	 * @return Pacific time
	 */
	public static TimeZone getPacific() {
		if (PACIFIC == null) {
			PACIFIC = chooseTimeZone(new String[] { "America/Los_Angeles", "PST8PDT", "PST" });
		}
		return PACIFIC;
	}

	private static TimeZone chooseTimeZone(String[] preferredChoices) {
		boolean[] availableChoices = new boolean[preferredChoices.length];
		for (int i = 0; i < availableChoices.length; i++) {
			availableChoices[i] = false;
		}
		String[] tz = TimeZone.getAvailableIDs();
		for (int i = 0; i < tz.length; i++) {
			String zoneName = tz[i];
			//System.out.println("checking: "+zoneName);
			for (int j = 0; j < preferredChoices.length; j++) {
				if (zoneName.equals(preferredChoices[j])) {
					availableChoices[j] = true;
				}
			}
		}
		for (int i = 0; i < availableChoices.length; i++) {
			if (availableChoices[i]) {
				//System.out.println("Using "+preferredChoices[i]);
				return TimeZone.getTimeZone(preferredChoices[i]);
			}
		}
		return null;
	}
	
	/**/
	// Test the time zones on current VM
	public static void main(String[] args) {
		System.out.println("Time Zone Test on JVM "+ System.getProperty("java.version"));
		DateFormat fmt = new SimpleDateFormat();
		
		Date date = new Date();
		fmt.setTimeZone(TimeZone.getTimeZone("EST"));
		System.out.println("Current time in EST  = "+fmt.format(date));
		fmt.setTimeZone(getEastern());
		System.out.println("Correct Eastern time = "+fmt.format(date));
		
		fmt.setTimeZone(TimeZone.getTimeZone("PST"));
		System.out.println("Current time in PST  = "+fmt.format(date));
		fmt.setTimeZone(getPacific());
		System.out.println("Correct Pacific time = "+fmt.format(date));
		
		System.out.println("EST = "+TimeZone.getTimeZone("EST"));
		System.out.println("PST = "+TimeZone.getTimeZone("PST"));
	}
	/**/
	
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround.

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2006-09-01 08:39:55.0

Please remove the EST time zone data file <JRE_HOME>/lib/zi/EST.
Run the tzupdater tool on the affected JRE with the -bc flag.
e.g <JAVA_HOME>/bin/java -jar tzupdater.jar -f -bc

In tzdata2005r (Olson time zone database), "EST" was added as follows.

# We generate the files specified below to guard against old files with
# obsolete information being left in the time zone binary directory.
# We limit the list to names that have appeared in previous versions of
# this time zone package.
# We do these as separate Zones rather than as Links to avoid problems if
# a particular place changes whether it observes DST.
# We put these specifications here in the northamerica file both to
# increase the chances that they'll actually get compiled and to
# avoid the need to duplicate the US rules in another file.
                                                                                              
# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone    EST              -5:00  -       EST
Zone    MST              -7:00  -       MST
Zone    HST             -10:00  -       HST
Zone    EST5EDT          -5:00  US      E%sT
Zone    CST6CDT          -6:00  US      C%sT
Zone    MST7MDT          -7:00  US      M%sT
Zone    PST8PDT          -8:00  US      P%sT

This addtion conflicts the JDK 1.1.x time zone IDs. We took the Olson time zone ID compatibility. This also means compatibility with Solaris and Linux as well.

As described in the TimeZone class documentation, the use of the 3-letter time zone IDs is deprecated. Please migrate to the Olson time zone IDs -- "America/New_York" for "EST".
Posted Date : 2006-09-01 14:21:51.0

There is a requirement that Java time zones are fully compatible with the Olson time zone data (4495052). It was obvious that 4495052 couldn't be supported without breaking JDK 1.1 compatibility, which was the reason why use of 3-letter time zone IDs was deprecated as of 4495052 support in 1.4.0.
Posted Date : 2006-09-03 23:17:18.0

Reopening this CR. We are evaluating a few options on this Olson vs. JDK 1.1 compatibility issue.
Posted Date : 2006-09-13 02:53:47.0

A compatibility mode flag will be added in JDK 7.
Posted Date : 2007-04-24 01:13:46.0

"EST", "HST", "MST"  are the three affected zones.
Posted Date : 2007-03-10 11:58:07.0

OK here is one for logic: IF THE 3 LETTER TIME ZONES ARE DEPRECATED THEN WHY CHANGE THEM?????

This change will afftect 10s of thousands of customers world-wide. Do you realize that because of this change, ALL existing Java code out there will need to be changed.

And for what? For a change in a deprecated time zone identifier?

I also want to point out that the "more correct" version was only added for EST, not for PST or CST, which have the exact same problem.
Please reconsider your position. The change has no benefits except to make EST "more correct" yet at the same time PST and CST and MST are not "more correct". 

So while the change has no benefits, it introduces many problems. All Applets that uses EST must be changed now. Keep in mind that most use this time zone because it was the only eastern time available in JDK 1.1. 

Breaking backwards compatibilty for nothing here...

If you are going to make a change like this, please add it to the Release Notes.  This is basic Software Engineering.  There is no reference to 4495052 or anything to do with this change.

Is this problem specific to JDK 1.5.0_08 and Java 6 beta 2 ? Or other versions have same issue?

The same issue happens in MST timezone also.

I've submitted a separate bug report but there is a more fundamental problem that is exposed by this change. Consider this tiny bit of code:

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");
                System.out.println(date);
        }
}


If you run this like this:
java -Duser.timezone=America/Los_Angeles Moh

Then here's the output

Wed Jun 06 12:00:00 PDT 2007

This is wrong - it should be 11:00:00 PDT. More seriously, this is a genuine 1 hour difference relative to epoch. 

This affects TZ conversions starting from EST to anything west.  Any TZ east of EST seems to convert just fine.

ie.  converting from UTC -> PDT (ok)

but.

converting from EDT (-4) -> PDT (-7) (wrong, off by one)

converting from MDT (-6) -> PDT (-7) wrong, ends up being equal)

converting from HDT (-9) -> PDT (-7) (wrong, adds one)

this only seems to affect certain timezones (eastern, mountain).  

> converting from HDT (-9) -> PDT (-7) (wrong, adds one)

The example above in regards to hawaii is fine as it's always -10 (not daylight savings time in hawaii)

I found that re-reunning tzupdater with "-f  -bc" does MORE than just remove the 3 files specified in alert 102836 (EST, HST, MST):
 
I copied original zi dir to zi-bu, ran "tzupdater -f -bc", then did "ls -1R" on each to output files, then ran this diff:
< zi:
---
> zi-bu:
10a11
> EST
14a16
> HST
16a19
> MST
...
< Asmara
---
> Asmera
...
< Atikokan
90d91
< Blanc-Sablon
101a103
> Coral_Harbour
...
< Winamac

...
< Faroe
---
> Faeroe

...
< Eucla
...
< Volgograd

And that does not check for size date diffs.  So what ELSE is going on here, and why is that considered equivalent to just removing the 3 specified files?

Will this defect causes issues if one uses default timezone. Thanks

Hey if  i am using jdk 1.5.0_07 then i don't think this issue will be problem for me.

Are these changes only related to Sun OS platforms? Using guide instructions from: http://www.apparentnetworks.com/pdf/Installing_Java_DST_Patch.pdf which works fine with a Win 2K platform, so just wondering if anyone's seen an issue working with win OS's, and also embedded xp thx