In JDK 1.1, 3-letter time zone IDs, which I think came from the Taligent OS, were used. "EST" is U.S. Eastern Time. Yes. It's confusing. Probably S stands for Standard and Summer. :-) When I took over the date/time API responsibility from IBM (ex-Taligent), I decided to change the whole time zone support mechanism in Java. The result went to J2SE 1.4. At that time I got a request that Java support the full set of the tz database IDs. Then, I gave the priority to the tz database IDs. "MET" (Middle East Time in JDK 1.1) was changed at that time. When "EST", "MST", and "HST" were added in tzdata2005r, if I remember correctly, I didn't change the "policy"... I had to agree to support the "compatibility mode flag" to deal with the conflicting requirements, tz database compatibility and JDK 1.1 compatibility. But I haven't implemented it yet... Thanks, Masayoshi Paul Eggert wrote:
John Stainforth <STAIN@uk.ibm.com> writes:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6466476 which contains the assertion: "This means that all legacy Applets and applications which used EST before are now broken".
This is all news to me. But it appears to be an issue with Java's old names for time zones, not with the Olson database per se. So you'll have to resolve it at the Java level.
You might just want to do what Sun is doing in JDK 7, and add a compatibility mode flag. Set the flag one way, and you get the traditional Java behavior where "EST" means eastern time with daylight saving (did it really mean that? wow, that's confusing). Set the flag the other way, and "EST" means eastern time without daylight saving (which is the traditional real-world meaning in this country, and is the traditional Olson interpretation as well). Perhaps you can ask Sun exactly how that flag will work, and how it will affect "HST", "MST", "PST", etc.
I'll CC: this message to the tz list to see whether others have noticed the problem.