Thanks Paul, it's a good idea to loop in Mark Davis. He may know more about the history of Etc/Unknown. Mark also has some context about this topic because he was part of the group that helped to ship CLDR-17111 which was the CLDR change that broke Chrome and prompted this thread. But I haven't spoken to Mark about this proposed change to TZDB so it'd be good to close the loop.

wouldn't it be better to change UTS#35's two instances
of the string "Etc/Unknown" to "Factory"? That way, UTS#35 would work
with both current and previous TZDB releases.

IMO it would have been ideal if UTS 35 and ICU had adopted Factory from the outset.

But ICU changing to Factory now after many years of Etc/Unknown would have significant compatibility issues. Many ICU callers expect "Etc/Unknown" to be returned by ICU for time zones that are not in CLDR. Callers could have used ICU's getUnknown() method  to avoid hardcoding, but judging by the 12.5K GitHub results for Etc/Unknown, not every developer got the memo. :-(

ICU generally avoids breaking changes like this. Given that ICU is UTS 35's largest implementation, it's unlikely that the Unicode folks would change the standard to something that ICU wouldn't be able to adopt.

Speaking of standards, for the last few years I've been helping to clarify parts of the ECMAScript spec that deal with time zones. Much of this new spec text is documenting how CLDR uses and adapts TZDB data. I've been meaning to post here on the TZ list to share this link in case folks are curious how JS engines use TZDB. Also, thanks so much for maintaining TZDB! JS developers are grateful. 

One unresolved issue in the ECMAScript spec is what to do about Etc/Unknown, because there's text in ECMA-402 that all browsers violate:

No String may be an available named time zone identifier unless 
it is a Zone name or a Link name in the IANA Time Zone Database

Although that language is from a PR of mine, I'm only describing existing behavior that has been in ECMAScript for ten years. To finally get browsers into compliance with the spec, I was planning to document Etc/Unknown as a special case in ECMA-402, but before proposing that change I wanted to check if there was interest in adding Etc/Unknown to TZDB instead. 

Best,
Justin


On Fri, Dec 6, 2024 at 10:51 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-12-06 18:10, Justin Grant via tz wrote:
> Hi TZ friends - Should the time zone identifier "Etc/Unknown" (standardized
> in Unicode Technical Standard 35 and used by the ICU
> <https://icu.unicode.org/> library that implements time zone support in all
> major web browsers, in Java, and in other platforms) be added to the IANA
> Time Zone Database?

If they chose "Etc/Unknown" because they wanted something that is not a
defined TZDB name, we shouldn't define it in TZDB, because then we'll
screw up whatever thing they had in mind.

On the other hand, if they want their internal name "unk" to correspond
to a TZDB name, wouldn't it be better to change UTS#35's two instances
of the string "Etc/Unknown" to "Factory"? That way, UTS#35 would work
with both current and previous TZDB releases.

Either way, it'd be helpful to get clarification from the maintainers of
TR35 as to what they want for "unk". I created an issue CLDR-18167[1]
asking about this. It's currently assigned to Mark Davis, the editor for
UTS#35.

[1]: https://unicode-org.atlassian.net/browse/CLDR-18167