`<chrono>`: Implement fallback mechanism for chrono's `[time.zone]`

[mnatsuhara]

Our implementation of a WG21-P0355 relies on information shipped with the Windows OS, which is only available in a form that we can use in more recent OS versions.

The affected pieces of WG21-P0355 are pieces of [time.zone] that need access to the IANA database, including [time.zone.leap]. Our initial implementation had no alternate strategy for getting the time zone data or knowing when new leap seconds occur, but we should come back and include a fallback implementation that is usable on older OSes. We will need to do some investigation as to what these alternate strategies should exactly look like, perhaps relying on timezoneapi.h and some mapping between Windows and IANA time zone names (our initial plan before finding that we could use the ICU DLL) and a hard-coded table of leap seconds (both past and future) that will need to be maintained.

Specifically, our limitations on Windows OS versions are:

• ICU DLL is only available in a digestible form (for us) in 19H1 and more recent OSes.
• The FILETIME struct only became leap-second-aware as of Server 2019 and Windows 10 October update.

[TzuChieh]

On Windows 7 with Visual Studio 16.11.3, I would get a std::system_error by simply calling std::chrono::current_zone() in an empty console application (looks like the error is from get_tzdb_list()). Can the error somewhat related to this?

[CaseyCarter]

On Windows 7 with Visual Studio 16.11.3, I would get a std::system_error by simply calling std::chrono::current_zone() in an empty console application (looks like the error is from get_tzdb_list()). Can the error somewhat related to this?

Yes, this is definitely your problem. The current implementation needs Windows 10, and recent-ish Windows 10 at that. Failure on Windows 7 is expected until we implement some kind of fallback as the OP mentions.

[TzuChieh]

Thank you for the information! I will work around the issue for the time being.

[mrboojum]

Is there an advised work around for this issue? I would like to deploy an app build with Visual Studio 2022 17.3.0 on Windows Server 2016 but on this OS i get an error during the execution of the last line:
auto tp_local = std::chrono::sys_seconds{}; mod_dt_in >> parse("%Y-%m-%d %H:%M:%S", tp_local); const auto mod_dt = std::chrono::clock_cast<std::chrono::utc_clock>(tp_local);

Is it possible to deploy the ICU.DLL to this OS and how could this be achieved?
Related to this; are there any other dependencies that should be deployed when building with VS2022 17.3.0 and deploying on Server 2016 and where can I find this information?

Thanks

I've got a workaround by deploying the icu.dll next to the app (loading this dll before the code above is invoked) and deploying the ICU data files to C:\Windows\Globalization\ICU. However I don't want to put this in production (obviously).

[jurihock]

Our customers have industrial grade PCs with preinstalled Windows 10 LTSC Build 17763 (Version 1809), where icu.dll is known to be missing. Unfortunately, it is not always possible to upgrade the existing Windows OS to a newer version, e.g. 1903. So we are limited by this circumstance in software development and unable to use the actually standardized C++ 20 features, especially std::chono functions.

Is there any chance to provide the missing icu.dll at least via Visual C++ redistributable package?

https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist

The current available redistributable is explicitly marked to support Windows Vista, 7, 8.1, 10, 11 and Visual Studio 2015, 2017, 2019, 2022.

It's a bit strange that support of even older OS versions is advertised but effectively not present.

See also C++20’s Extensions to Chrono Available in Visual Studio 2019 version 16.10

While our current implementation relies on the availability of the ICU DLL in more recent OS versions, we have plans to revisit the issue and investigate implementing a fallback for older operating systems.

[doomlaur]

In order to support older versions of Windows and also because of performance reasons (as explained in #2842), we were forced to write a few wrappers that handle old versions of Windows and improve performance.

In short:

1. We have wrappers for functions like current_zone() and default_zone() that handle exceptions and return nullptr if no time zone support is available. Furthermore, we have a function called are_time_zones_available() that calls std::chrono::get_tzdb_list() which throws an exception if no time zone database is available.
2. We have another round of wrappers around the previously mentioned functions that cache their values for performance reasons, because for our use cases we can ignore time zone changes while our software is running.
3. We have extended std::chrono::zoned_time and overrode get_local_time() and operator=(const std::chrono::local_time<Duration> &) to handle old versions of Windows correctly. Our wrapper allows using nullptr as a time zone, in which case it instead uses mktime() (for get_local_time()) and localtime() / localtime_s() (for operator= with a local_time) to still work on older versions of Windows, in which case it always uses the local time.
4. We made sure that our code uses our own zoned_time everywhere instead of std::chrono::zoned_time, to avoid surprises due to the fact that we cannot override virtual functions, because std::chrono::zoned_time has not been made to support inheritance.

Using inheritance with types that don't have virtual functions (because they have not been made to inherit from) is a bad idea, however, due to the circumstances, we decided that this was the best solution.

Also, caching as much as we could was critical for us, as all access to the ICU library is currently very slow for high-performance software. We even added the option of forcing legacy time handling (using localtime()/mktime()) even on modern versions of Windows whenever time zone handling is not needed, in order to further improve performance. This way we have time zones whenever we need them, and high performance otherwise.

[doomlaur]

I almost forgot: there's also a related issue about clock_cast in #2446, if anyone is interested. As explained there, I also wrote a small wrapper that ignores leap seconds.

[zlojvavan]

mrboojum

I've got a workaround by deploying the icu.dll next to the app (loading this dll before the code above is invoked) and deploying the ICU data files to C:\Windows\Globalization\ICU

wonder what is the preferred source for getting icu.dll and other required files? thank you

[zlojvavan]

also had to implement some custom classes even with Hinnant's date lib last year but not for performance reason but due to different set of problems such as say failed attempts to download tz database file, parse it, requirements to use in late stages of app finalization (after tzdb instance destruction), support of boost::serialization etc.

funny that attempts to compile it with gcc revealed bug in 11.3 (something with type_traits and failing is_constructible though I did not report it, found some workaround)

now that I adopted codebase to switch between date and chrono depending on c++ and libc version and rebuilt the project as c++20 I faced the problem with missing icu.dll on my win 7 so cannot test chrono [time.zone] support at the moment

[doomlaur]

I've got a workaround by deploying the icu.dll next to the app (loading this dll before the code above is invoked) and deploying the ICU data files to C:\Windows\Globalization\ICU. However I don't want to put this in production (obviously).

Interesting. I was under the impression that icu.dll will only be loaded from system32, because the C++ Standard Library of Visual Studio asks for this explicitly:

const HMODULE _Icu_module = LoadLibraryExW(L"icu.dll", nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);

The documentation for LoadLibraryExW says that the option LOAD_LIBRARY_SEARCH_SYSTEM32 does the following:

If this value is used, %windows%\system32 is searched for the DLL and its dependencies. Directories in the standard search path are not searched.

Maybe I might have misunderstood how this function actually loads DLLs?

EDIT: For the case you also want to build workarounds with icu.dll to get it working on very old versions of Windows, also note that using LoadLibraryExW with LOAD_LIBRARY_SEARCH_SYSTEM32 also has the following requirements:

Windows 7, Windows Server 2008 R2, Windows Vista and Windows Server 2008: This value requires KB2533623 to be installed.
Windows Server 2003 and Windows XP: This value is not supported.