[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

[Yoshito Umaoka]

> > (BTW, you might disagree that we set such
> > assumption. I think TZ database does not prohibit a same abbreviation
> > used for standard and daylight at a time, although it is unlikely.)
> 
> Not only does tzdb not prohibit it, that feature was long used in 
Australian 
> timestamps, as it matched more-traditional Australian practice. One can 
still 
> follow this more-traditional practice by using POSIX TZ settings like 
> TZ='EST-10EST,M10.1.0,M4.1.0/3' which uses "EST" for both Eastern 
> Standard Time 
> and Eastern Summer Time. If CLDR assumes that names or abbreviations 
must be 
> unique, that's a problem that should get fixed somehow.
> 

In this example, if "EST" cannot distinguish between standard time and
summer time, then we don't use the abbreviations. The goal of CLDR is to 
provide
names that people in a locale can reasonably understand - and 
standard/daylight
names requires that people can distinguish one from another.

In this case, "EST" can be "generic" name in CLDR. The concept of 
"generic" name
is not in TZ db database.


Anyway, CLDR tend to exclude many short names, because these abbreviations
are not understood by people out of regions.

> > If TZ database project insists to make the change, CLDR project has to
> > decide whether we should swap standard/dalight name in CLDR, and if
> > we do, when is the right time
> 
> I'm proposing a patch so that the CLDR project doesn't need to make such 
an 
> abrupt swap. CLDR can have a transition period as long as you like, 
> during which 
> CLDR will work with both current and proposed tzdb.
> [attachment "cldr.diff" deleted by Yoshito Umaoka/Westford/IBM] 

I personally think we don't want to introduce artificial names introduced 
here.
If "Irish Standard Time" is the official term, also recognized by people 
in
Ireland, specifying time in summer there, CLDR should not change it just 
for
this purpose.

-Yoshito


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180126/ccc14602/attachment.html>