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

[Masayoshi Okutsu]

Paul Eggert wrote:
> I suspect Java picked "EST" up only in 2005r because Java ignores the
> "backward" file.
>   

Java doesn't ignore the backward file, but it has its own backward file 
which has the priority. "EST" is an alias of "America/New_York" in the 
Java's backward file. However, when the EST data file exists, Java 
runtime takes the data file.

So, a simple workaround is to remove the data file. That enables the 
(Java) alias.

> In retrospect perhaps we should have omitted these System V names, as
> they're now causing more trouble with Java than they're worth.
>
> Or perhaps we should move them to the "systemv" file now.  But
> that is Arthur's call.
>
> From the Java point of view, I would simply remove all the System V
> names from Java.  I don't see the point of them; they just cause
> trouble.  That is, I would pretend that the following entries don't
> exist in the "northamerica" file, so that you can continue with the
> traditional Java interpretation for them.
>
> # 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

Time zone data for Java is maintained by multiple organizations at Sun. 
So, I thought it'd be too complicated if all time zone data maintainers 
at Sun had to remove these lines every time a new tzdata is released. 
The use of the 3-letter time zone IDs was deprecated years ago. But 
seems like there are applications that hard code "EST" in its program.

Thanks,
Masayoshi