<chrono>: Cannot parse "23:59:59" as system_clock::time_point on older Windows versions

[statementreply]

Describe the bug
Originally reported at DevCom-1465261.

auto& db = std::chrono::get_tzdb_list(); throws the runtime exception “The specified module could not be found.” on windows server 2019.
[...]
I am only dealing with UTC but the chrono implementation accesses the tzdb regardless in certain special cases even though it never actually uses the result.
e.g. parsing a date string containing the time “23:59:59” causes a tzdb load internally.

Command-line test case

C:\Users\He\source\test>type chronat.cpp

#include <chrono>
#include <iostream>
#include <sstream>
#include <stdexcept>
#include <string>

using namespace std;
using namespace std::chrono;

int main() {
    try {
        system_clock::time_point t;
        if (istringstream{"2021-08-28 23:59:59"} >> parse("%F %T"s, t)) {
            cout << t << "\n";
        } else {
            cout << "parse failed\n";
        }
    } catch (const exception& e) {
        cout << "error: " << e.what() << "\n";
    }
    return 0;
}

C:\Users\He\source\test>cl /EHsc /W4 /WX /std:c++latest chronat.cpp
用于 x86 的 Microsoft (R) C/C++ 优化编译器 19.30.30423 版
版权所有(C) Microsoft Corporation。保留所有权利。

/std:c++latest 作为最新的 C++
working 草稿中的语言功能预览提供。我们希望你提供有关 bug 和改进建议的反馈。
但是，请注意，这些功能按原样提供，没有支持，并且会随着工作草稿的变化
而更改或移除。有关详细信息，请参阅
https://go.microsoft.com/fwlink/?linkid=2045807。

chronat.cpp
Microsoft (R) Incremental Linker Version 14.30.30423.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:chronat.exe
chronat.obj

On Windows 10 21H1:

C:\Users\He\source\test>.\chronat.exe
2021-08-28 23:59:59.0000000

On Windows 7 SP1:

C:\Users\He\Desktop>.\chronat.exe
error: 参数错误。

Expected behavior
On older systems without leap second support, parsing "23:59:59" as system_clock::time_point should work just fine.

STL version
Microsoft Visual Studio Community 2022 Preview (64 位)
版本 17.0.0 Preview 3.1

[MattStephanson]

Is it feasible to populate the tzdb_list with leap seconds, but no time zones, if ICU isn't found? I think there are some systems that support leap seconds but don't have ICU, so there would be some value to not falling back to a static leap second list in that case.

[StephanTLavavej]

@MattStephanson That would affect a single Win10 version, but it happens to be the Windows Server 2019 version, so it might be worthwhile. https://github.com/microsoft/STL/wiki/Changelog#vs-2019-1610 mentioned:

Specifically, updating the leap second database requires Windows 10 version 1809 or later, and time zones require icu.dll which is provided by Windows 10 version 1903/19H1 or later. This applies to both client and server OSes; note that Windows Server 2019 is based on Windows 10 version 1809.

@statementreply I agree with your expected behavior.

[statementreply]

After a second thought, I think there are two separate issues here:

1. Accessing leap second info fails if ICU is not available.
2. If a date/time string represents 23:59:59 UTC deleted by a negative leap second, which is otherwise a valid value for sys_time, should parsing sys_time from it succeed or fail?

[MattStephanson]

After a second thought, I think there are two separate issues here:

True, but even if we changed course on checking leap second validity, we'd still have to fix (1) because it's not specific to sys_time or validation. Many operations implicitly need the leap second list, such as formatting or parsing utc_time and various clock_cast paths.

[mnatsuhara]

Thanks for bringing this up, noting that #1911 is also related.