[tz] Java & Rearguard

[Steven R. Loomis]

Paul, 
CLDR keys off either tzdb ids ( example: Indiana/Marengo https://unicode.org/cldr/charts/latest/by_type/timezones.north_america.html#56d801000f7f09e9 <https://unicode.org/cldr/charts/latest/by_type/timezones.north_america.html#56d801000f7f09e9> ) or “metazones”, see https://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Names <https://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Names>

The metazones are groupings used for translation (formatting) of dates only, not for time calculation.

In this specific example, the metazone “Africa_Western”  encompasses Africa/Brazzaville, Africa/Bangui, and others.

                        <timezone type="Africa/Windhoek">
                                <usesMetazone to="1990-03-20 22:00" mzone="Africa_Southern"/>
                                <usesMetazone to="1994-03-20 22:00" from="1990-03-20 22:00" mzone="Africa_Central"/>
                                <usesMetazone to="2017-10-23 22:00" from="1994-03-20 22:00" mzone="Africa_Western"/>
                                <usesMetazone from="2017-10-23 22:00" mzone="Africa_Central"/>
                        </timezone>

--
Steven R. Loomis | @srl295 | git.io/srl295



> El jun. 1, 2019, a las 12:05 a. m., Paul Eggert <eggert at cs.ucla.edu> escribió:
> 
> Brian Inglis wrote:
>> The query is what does the (CLDR/ICU) label apply to: the offset or the time
>> period?
>> The label would seem to apply to the period of Location Summer Time, Location
>> Winter Time, Location Daylight Saving Time, Location Standard Time, rather than
>> denoting the time zone offset.
>> So what then should you label the extra periods: use the same labels as the
>> previous uses of the same offsets, or give the extra periods their own unique
>> labels, and what should those unique labels indicate?
> 
> I'm afraid I'm having trouble connecting your question to the CLDR tables, because I don't understand how CLDR works in detail. Looking at <https://unicode.org/cldr/charts/latest/by_type/> it appears that CLDR doesn't key on the string "Africa/Casablanca" when trying to generate labels for time zones. Instead, it keys on strings like "Africa Western" (I don't know where these strings come from; they were never in tzdb) and translates these keys to strings like "heure d’Afrique de l’Ouest" (French). The list of such keys for African time zones is:
> 
> Africa Central
> Africa Eastern
> Africa Southern
> Africa Western
> Cape Verde
> French Southern
> Indian Ocean
> Mauritius
> Reunion
> Seychelles
> 
> These mostly appear to reflect abbreviations that were formerly in tzdb (e.g., MUT for "Mauritius Time") but were removed from tzdb in 2017 on the grounds that tzdb should reflect existing practice instead of imposing its own invented abbreviations. Evidently CLDR has more of a packrat mentality, and does not remove such entries even if the upstream source (tzdb in this case) no longer uses them even indirectly. And it's not clear to me how a program would automatically map Africa/Casablanca's "+01" and "+02" to "Africa Western" and "Morocco Ramadan" (or whatever).
> 
> The whole thing is a bit of a mess, I'm afraid. I'm not sure we'd be doing CLDR favors by inventing names like "Morocco Ramadan Time", as this would merely give translators more make-work that in practice would be useless or confusing or both.

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