[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