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
