Tested x86_64-linux. Pushed to trunk. -- >8 --
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the library, there's the one defined inline in <chrono> (to avoid loading the tzdb for the common case) and another in a testcase. This updates them to note that there are no new leap seconds in 2024 either, until at least 2024-12-28. libstdc++-v3/ChangeLog: * include/std/chrono (__get_leap_second_info): Update expiry time for hardcoded list of leap seconds. * testsuite/std/time/tzdb/leap_seconds.cc: Update comment. --- libstdc++-v3/include/std/chrono | 2 +- libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono index a59af34567c..3a9751781d2 100644 --- a/libstdc++-v3/include/std/chrono +++ b/libstdc++-v3/include/std/chrono @@ -3243,7 +3243,7 @@ namespace __detail }; // The list above is known to be valid until (at least) this date // and only contains positive leap seconds. - const sys_seconds __expires(1703721600s); // 2023-12-28 00:00:00 UTC + const sys_seconds __expires(1735344000s); // 2024-12-28 00:00:00 UTC #if _GLIBCXX_USE_CXX11_ABI || ! _GLIBCXX_USE_DUAL_ABI if (__ss > __expires) diff --git a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc index f5401a24526..5999635a89f 100644 --- a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc +++ b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc @@ -21,7 +21,7 @@ void test_load_leapseconds() { std::ofstream("leapseconds") << R"( -# These are all the real leap seconds as of 2022: +# These are all the real leap seconds as of 2024: Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S -- 2.43.2