Re: Predictable problems with 3-character time zones, especially the EST/EST5EDT split.
John Stainforth <STAIN@uk.ibm.com> writes:
Our understanding is that:
a) Before tzdata2005r... "EST" refers to the zone that is GMT-5 in Winter and GMT-4 in Summer, then .... b) Effective from tzdata2005r, "EST" refers only to some special area(s) within the Eastern region that are GMT-5 all the year round.
That sounds right as far as Java is concerned. But it's not a property of tzdata, it's a property of Java. As far as the tz database is concerned, TZ="EST" has never given you daylight-saving time. Here's the history. Before tzdata2005m, there was no TZ="EST" in the tz database. But we had a desire to support the old 1980s System V TZ names, "EST" being one of them, where "EST" was used in Indiana and meant eastern time with no daylight saving. I don't now recall why we were so focused on being backward-compatible with a long-dead system, but hey! we try hard to be backward-compatible. So, in tzdata2005m through tzdata2005q, TZ="EST" was implemented as an alias for America/Panama in the "backward" file, under the theory that Panama has observed UTC-5 since standard time was introduced in 1908. But this isn't satisfactory, as it mishandles time stamps before 1908, and maybe Panama will observe DST some day. So in tzdata2005r "EST" was given a zone in its own right, in the "northamerica" file. I suspect Java picked "EST" up only in 2005r because Java ignores the "backward" file. 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
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
participants (2)
-
Masayoshi Okutsu -
Paul Eggert