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 <https://unicode-org.atlassian.net/browse/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() <https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1TimeZone...> method to avoid hardcoding, but judging by the 12.5K GitHub results for Etc/Unknown <https://github.com/search?q=%22Etc%2FUnknown%22&type=code>, 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 <https://402.ecma-international.org/2.0/index.html#sec-canonicalizetimezonena...> 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 <https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database> 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 <https://402.ecma-international.org/2.0/index.html#sec-canonicalizetimezonena...>. 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.