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