[tz] Timezone selectors (was RES: Timezone for Brazil)

[Matt Johnson-Pint]

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).

https://github.com/unicode-org/icu/blob/3d1dee683743c4578ced479c10b1fbe25aeacc9a/icu4c/source/i18n/tzgnames.cpp#L594

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.

-Matt


On Fri, Oct 13, 2023 at 5:47 PM Guy Harris <gharris at sonic.net> wrote:

> On Oct 12, 2023, at 10:24 AM, Matt Johnson-Pint <mattjohnsonpint at gmail.com>
> wrote:
>
> > 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
> https://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names
>
> The only mention of 184 days I see there is:
>
>         Type Fallback
>
>         When a specified type (generic, standard, daylight) does not exist:
>
>             1. If the daylight type does not exist, then the metazone
> doesn’t require daylight support. For all three types:
>                 1. If the generic type exists, use it.
>                 2. Otherwise if the standard type exists, use it.
>             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.
>                 1. Example: "Mountain Standard Time" for Phoenix
>                 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).
>
> 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".
>
> I'm not sure what "not available" means in this context, but, in the tip
> of the main branch of https://github.com/unicode-org/cldr.git, the file
> common/main/en.xml has
>
>                         <metazone type="America_Mountain">
>                                 <long>
>                                         <generic>Mountain Time</generic>
>                                         <standard>Mountain Standard
> Time</standard>
>                                         <daylight>Mountain Daylight
> Time</daylight>
>                                 </long>
>                                 <short>
>                                         <generic>MT</generic>
>                                         <standard>MST</standard>
>                                         <daylight>MDT</daylight>
>                                 </short>
>                         </metazone>
>
> and common/supplemental/metaZones.xml has
>
>                         <timezone type="America/Phoenix">
>                                 <usesMetazone mzone="America_Mountain"/>
>                         </timezone>
>
> so I'm not sure why they're giving Phoenix as an example of a location
> where the generic type is "not available".
>
> And common/main/en.xml has
>
>                         <metazone type="Brasilia">
>                                 <long>
>                                         <generic>Brasilia Time</generic>
>                                         <standard>Brasilia Standard
> Time</standard>
>                                         <daylight>Brasilia Summer
> Time</daylight>
>                                 </long>
>                         </metazone>
>
> common/main/pt.xml has
>
>                         <metazone type="Brasilia">
>                                 <long>
>                                         <generic>Horário de
> Brasília</generic>
>                                         <standard>Horário Padrão de
> Brasília</standard>
>                                         <daylight>Horário de Verão de
> Brasília</daylight>
>                                 </long>
>                                 <short>
>                                         <generic>BRT</generic>
>                                         <standard>BRT</standard>
>                                         <daylight>BRST</daylight>
>                                 </short>
>                         </metazone>
>
> and common/supplemental/metaZones.xml has
>
>                         <timezone type="America/Sao_Paulo">
>                                 <usesMetazone mzone="Brasilia"/>
>                         </timezone>
>
> so, at least in English and Portuguese, the common name is available for
> America/Sao_Paulo, at least.
>
> 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.
>
> ("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.)
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20231016/93c903cb/attachment.htm>