May be prudent to keep Etc/Factory and Etc/Unknown separate to guard against the possibility that a vendor does something funky with Factory (such as automatically modifying the distribution so that Factory is their local time). There's a small price to pay given the small sizes of the existing Factory and proposed Unknown binaries.

    @dashdashado

On Fri, Dec 6, 2024, 9:11 PM Justin Grant via tz <tz@iana.org> wrote:
Hi TZ friends - Should the time zone identifier "Etc/Unknown" (standardized in Unicode Technical Standard 35 and used by the ICU 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? 

Etc/Unknown would behave the same as the existing time zone identifier "Factory". Ideally, Etc/Unknown could be a Zone and Factory could be turned into a Link pointing to Etc/Unknown, because both of them have the meaning of "the time zone of this computer is not known" but Etc/Unknown is more self-describing and is better aligned with modern Zone naming conventions.

Here's more context: "Etc/Unknown" is standardized in https://unicode.org/reports/tr35/#Time_Zone_Identifiers. Here's the relevant text from the standard:

> There is a special code "unk" for an Unknown or Invalid time zone.
> This can be expressed in the tz database style ID "Etc/Unknown",
> although it is not defined in the tz database.

Following this standard, Etc/Unknown is returned by ICU when the time zone of a computer cannot be determined. Here's an example of an ICU method that can return Etc/Unknown: icu::TimeZone::detectHostTimeZone().
 
The fact that Etc/Unknown looks like an IANA identifier but is not actually in TZDB has been a long-running source of problems. Most recently, this week Chrome is rushing out a patch that reverted a recent change that added support for the "Factory" zone by making it an alias for "Etc/Unknown". GIven that ICU previously didn't recognize Factory and so returned Etc/Unknown for computers in the Factory zone, this was assumed by everyone to be a safe change. But this change turned out to break some 3rd-party libraries and had to be reverted.

After discussing this recent bug with engineers at Google, our consensus was that it'd be helpful for the time zone ecosystem if Etc/Unknown stopped being a special case and started being a regular Zone in the IANA Time Zone database. Especially if we could Link-ify Factory at the same time so that Zone picker UIs won't have two distinct "I don't know what time zone this is" choices.

Thanks for considering this proposal.

Best,
Justin Grant