Yes, that would suffice. It would, however, be a bit cleaner (and easier for programmers to understand) if CLDR could just reference the TZDB for all identifiers. On Sat, Dec 7, 2024 at 10:51 PM Guy Harris <gharris@sonic.net> wrote:
On Dec 7, 2024, at 9:15 PM, Mark Davis Ⓤ <mark@unicode.org> wrote:
That is, the API is returning a value indicating that what you asked for doesn't have a well-defined answer.
Then, presumably, all that is needed is a guarantee from the tzdb maintainers that "Etc/Unknown" will never be assigned to a timezone.
Given that tzset() does not return a success/failure indication, and that the 2024 Single UNIX Specification's page for taste() says nothing about the behavior if TZ isn't set to a valid value (for some definition of "valid"):
https://pubs.opengroup.org/onlinepubs/9799919799/functions/tzset.html
nor does the 2024 Single UNIX Specification page on environment variables specify the the value of TZ in a fashion that permits all possible values to be determined to be valid or invalid:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html
the behavior after calling tzset() if TZ is set to Etc/Unknown isn't specified anywhere, and it could be the same as the behavior if tzset("This/Does/Not/Exist") is called on a system that just uses the tzdb files, so there doesn't appear to be any need to put Etc/Unknown into the database - a guarantee that Etc/Unknown will never be used for any timezone in the tzdb should suffice