<div dir="ltr">Unfortunately, ICU always uses the 184 day rule to choose the standard name when formatting generic non-location names, regardless of whether a more suitable generic name exists or not. See the implementation of the formatGenericNonLocationName function (search for usages of the kDstCheckRange constant).<div><br><div><div><a href="https://github.com/unicode-org/icu/blob/3d1dee683743c4578ced479c10b1fbe25aeacc9a/icu4c/source/i18n/tzgnames.cpp#L594">https://github.com/unicode-org/icu/blob/3d1dee683743c4578ced479c10b1fbe25aeacc9a/icu4c/source/i18n/tzgnames.cpp#L594</a><br></div></div></div><div><br></div><div>I agree - this is entirely too complicated. The fact is that currently, ICU generic names (of any form) are designed to apply in the context of having a date, time, and time zone - not for choosing a time zone from a list. Sometimes those are the same, but not always.</div><div><br></div><div>-Matt</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 13, 2023 at 5:47 PM Guy Harris <<a href="mailto:gharris@sonic.net">gharris@sonic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Oct 12, 2023, at 10:24 AM, Matt Johnson-Pint <<a href="mailto:mattjohnsonpint@gmail.com" target="_blank">mattjohnsonpint@gmail.com</a>> wrote:<br>
<br>
> Re-reading the thread, it seems part of the question is why the word "Standard" is present in "(UTC-03:00) Brasilia Standard Time (Sao Paulo)". That's due to the 184 day rule, specified in the "TypeFallback" section of the TR35 spec that ICU uses to interpret CLDR data. See <a href="https://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names" rel="noreferrer" target="_blank">https://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names</a><br>
<br>
The only mention of 184 days I see there is:<br>
<br>
Type Fallback<br>
<br>
When a specified type (generic, standard, daylight) does not exist:<br>
<br>
1. If the daylight type does not exist, then the metazone doesn’t require daylight support. For all three types:<br>
1. If the generic type exists, use it.<br>
2. Otherwise if the standard type exists, use it.<br>
2. Otherwise if the generic type is needed, but not available, and the offset and daylight offset do not change within 184 day +/- interval around the exact formatted time, use the standard type.<br>
1. Example: "Mountain Standard Time" for Phoenix<br>
2. Note: 184 is the smallest number that is at least 6 months AND the smallest number that is more than 1/2 year (Gregorian).<br>
<br>
2. says "if the generic type is needed, *but not available*, and a transition doesn't occur within the 184-day interval, fall back the standard type"; it doesn't appear to say "never use the generic type even if it *is* available".<br>
<br>
I'm not sure what "not available" means in this context, but, in the tip of the main branch of <a href="https://github.com/unicode-org/cldr.git" rel="noreferrer" target="_blank">https://github.com/unicode-org/cldr.git</a>, the file common/main/en.xml has<br>
<br>
<metazone type="America_Mountain"><br>
<long><br>
<generic>Mountain Time</generic><br>
<standard>Mountain Standard Time</standard><br>
<daylight>Mountain Daylight Time</daylight><br>
</long><br>
<short><br>
<generic>MT</generic><br>
<standard>MST</standard><br>
<daylight>MDT</daylight><br>
</short><br>
</metazone><br>
<br>
and common/supplemental/metaZones.xml has<br>
<br>
<timezone type="America/Phoenix"><br>
<usesMetazone mzone="America_Mountain"/><br>
</timezone><br>
<br>
so I'm not sure why they're giving Phoenix as an example of a location where the generic type is "not available".<br>
<br>
And common/main/en.xml has<br>
<br>
<metazone type="Brasilia"><br>
<long><br>
<generic>Brasilia Time</generic><br>
<standard>Brasilia Standard Time</standard><br>
<daylight>Brasilia Summer Time</daylight><br>
</long><br>
</metazone><br>
<br>
common/main/pt.xml has<br>
<br>
<metazone type="Brasilia"><br>
<long><br>
<generic>Horário de Brasília</generic><br>
<standard>Horário Padrão de Brasília</standard><br>
<daylight>Horário de Verão de Brasília</daylight><br>
</long><br>
<short><br>
<generic>BRT</generic><br>
<standard>BRT</standard><br>
<daylight>BRST</daylight><br>
</short><br>
</metazone><br>
<br>
and common/supplemental/metaZones.xml has<br>
<br>
<timezone type="America/Sao_Paulo"><br>
<usesMetazone mzone="Brasilia"/><br>
</timezone><br>
<br>
so, at least in English and Portuguese, the common name is available for America/Sao_Paulo, at least.<br>
<br>
Perhaps it's not as simple as "to find the generic, standard, and daylight saving time long and short names for a given tzid, find its metazone from common/supplemental/metaZones.xml and use the values there, based on the date and time if necessary", but, if so, *that* would strike me as a sign that this process is Too Complicated and that the tzdb and CLDR people should figure out something better.<br>
<br>
("Based on the date and time if necessarily" is for handling cases where a given tzdb region goes from Eastern Freedonian Time to Central Freedonian Time or something such as that, wherein Europe/Freedoniaville would be mapped to the "Europe_Eastern_Freedonia" metazone before the transition and "Europe_Central_Freedonia" metazone at and after the transition; moves such as that are rare, but they do happen and there are instances of that in the tzdb.)<br>
<br>
I.e., it appears that the 184 day rule is part of a *workaround* for cases in which a metazone has a "standard time" name for the time, and possibly a "daylight saving time" name for the time, but has no "generic" name for the time; it's *not* an override that causes the "generic" time never to be used.</blockquote></div>