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

[Guy Harris]

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.