On Dec 8, 2024, at 1:04 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Many of these implementations, including tzcode, have a different mechanism for detecting whether a TZ string is known. In tzcode, for example, tzalloc("Etc/Unknown") returns a null pointer, following NetBSD's precedent.
Unfortunately, tzset() doesn't return a value, so it can't indicate that TZ is set to a value not in the tzdb. (And, unfortunately, there's also no way to indicate "well, we *do* have a file for that tzid, but it's not a valid file" - e.g., tzh_timecnt specifies more transition times than are in the file - in a way that it can be distinguished from "we don't have a file for that tzid.)
All in all it sounds better to let sleeping dogs lie and document the guarantee that Guy suggested, without changing TZDB's data. As you write, that would suffice. It means that JavaScript can return the equivalent of "Etc/Unknown" in places where tzcode returns a null pointer - to some extent JS simply uses a string where C uses a null pointer to represent failure. Proposed patch attached and installed into the TZDB development repository.
I agree. For "It would, however, be a bit cleaner (and easier for programmers to understand) if CLDR could just reference the TZDB for all identifiers.", does "reference the TZDB" mean "refer to a name that corresponds to a file" or does it just mean "refer to something that the tzdb has assigned"? If the latter, this suffices. (What happens if I set LANG to unk_US? Is there a guarantee that here will be information for that locale, does setlocale() return NULL, or what? This strikes me as an analogous case.)