Predictable problems with 3-character time zones, especially the EST/EST5EDT split.

Paul Eggert eggert at CS.UCLA.EDU
Mon Dec 18 08:35:36 UTC 2006


John Stainforth <STAIN at uk.ibm.com> writes:

> http://www-1.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&uid=swg21250247

Weird.  That URL claims Indiana does not observe daylight saving time,
but it does (starting this year).

> 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.



More information about the tz mailing list