[tz] Java & Rearguard
Paul Eggert
eggert at cs.ucla.edu
Sat Jun 8 18:05:39 UTC 2019
Mark Davis ☕️ wrote:
> CLDR has misleading IDs for the different variants of
> a zone name:
>
> generic, standard, daylight.
>
> While these are invisible to users, they can be misleading to programmers.
> Names that would have been more reflective of the intended use would have
> been something like:
>
> generic, offset0, offset1
Although that would be an improvement, it's not enough because it's not
historically correct to couple UTC offsets to zone names. For example, tzdb says
America/Los_Angeles historically has had three offsets (-07:52:58, -08, -07) but
has had four time zone abbreviations because -07 has usually been abbreviated
PDT but was abbreviated PWT during 1942-5. And if California moves to permanent
-07 as it is threatening to do, -07 may be called MST or PST soon in Los Angeles
with tm_isdst equal to 0. This all works fine in tzdb, but it appears that
CLDR/Java cannot handle it.
CLDR/Java has gotten away so far with these glitches because they have affected
only timestamps from decades ago (Ireland circa 1970, US 1942-5, etc.) so hardly
anybody cares. However, the US and Europe are quite likely to change time zone
names and/or rules in the near future, in such a way that these problems will
happen with contemporaneous timestamps. When this happens, lots of people will
rightly complain (and many people will mistakenly blame tzdb :-).
Now is a good time for Java and CLDR to fix this. Better now than six months
from now.
More information about the tz
mailing list