* Guy Harris via tz: > On Dec 7, 2024, at 9:15 PM, Mark Davis Ⓤ <[email protected]> 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
It's also not possible to detect on some POSIX-like systems (that use the IANA database) whether the system administrator has used a specific IANA identifier to configure the system. Applications only see the data blob describing the time zone behavior and (sometimes) abbreviations, and that doesn't include the identifier. Thanks, Florian
