What's up with tz.cpp in libc++? (original) (raw)

// TODO TZDB Implement the Windows mapping in tzdb::current_zone

_LIBCPP_BEGIN_NAMESPACE_STD

namespace chrono {

// This function is weak so it can be overriden in the tests. The
// declaration is in the test header test/support/test_tzdb.h
_LIBCPP_WEAK string_view __libcpp_tzdb_directory() {
#if defined(__linux__)
  return "/usr/share/zoneinfo/";
#else
#  error "unknown path to the IANA Time Zone Database"
#endif
}

This looks only half done. Is LLVM’s libc++ supposed to support Windows?

As mentioned in the TODO this needs to be supported Windows. However the whole time zone implementation in libc++ is still incomplete and under development.

Since Windows, unlike POSIX systems, does not ship the IANA database I’ve not looked at how to support this on Windows. Since I don’t have access to Windows systems I’ll need assistance to get this working on Windows.

jwakely May 2, 2024, 8:07pm 3

I think MSVC STL relies on ICU for time zone information:

Libstdc++ has the ability to bundle a copy of the tzdata.zi file from the IANA database, so that it is still usable on systems that don’t provide one as part of the OS. That obviously has the major downside that it’s static and so becomes outdated every few months when there’s a new version of the IANA DB.

I’m quite sure they do.

We considered that for libc++ too, but in the end decided we didn’t want to go that route. I think we need to go that route on Windows and have it in the LLVM Windows package. But then we need to consider how users can update the database.

We still need to have Windows specific call to get local time zone and then we need to convert the Windows time zone name to the IANA name. Based on Howard’s code this contains the conversion table. This does not seem very complicated, but it requires access to a Windows system.

Alternatively we could use the same approach as MSVC STL on Windows. I’m quite sure the ICU database they use is provided by Windows and not the MSVC STL runtime library.

Just noting that generic windows support (e.g. assuming a unix-style TZDB, with a path to it provided through an environment variable) would already be highly useful for our distribution, where we have no problem to ship up-to-date tzdata also on windows (that ends up in some environment-specific path like $PREFIX/share/zoneinfo resp. %PREFIX%\share\zoneinfo).