std::chrono::locate_zone returns null pointer on some platforms

Goal

Assess whether a program can depend on std::chrono::locate_zone to return a valid std::chrono::time_zone const* for a given IANA name when the same binary is executed on different operating systems or when the host’s time‑zone database is outdated or missing.

Constraints and uncertainty

The C++20 standard does not require an embedded zone database; implementations obtain zone information from the host system (e.g., /usr/share/zoneinfo on POSIX) or may provide an empty fallback. Consequently, the availability of a particular zone is implementation‑defined and can vary between Linux, macOS, Windows, and embedded environments. When the underlying tzdata does not contain the requested name, locate_zone returns a null pointer, and the program must handle this case.

What conditions cause std::chrono::locate_zone to return a null pointer? How can a portable program detect and handle missing zones reliably? Is there a standard‑conforming way to enumerate the set of zone names that the implementation can load at runtime?