public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r14-9406] libstdc++: Do not require a time-of-day when parsing sys_days [PR114240] Date: Sat, 9 Mar 2024 00:29:34 +0000 (GMT) [thread overview] Message-ID: <20240309002934.E7F00385E445@sourceware.org> (raw) https://gcc.gnu.org/g:3e8ee03edd018eed43444755f601cdb9d5931654 commit r14-9406-g3e8ee03edd018eed43444755f601cdb9d5931654 Author: Jonathan Wakely <jwakely@redhat.com> Date: Fri Mar 8 16:15:57 2024 +0000 libstdc++: Do not require a time-of-day when parsing sys_days [PR114240] When parsing a std::chrono::sys_days (or a sys_time with an even longer period) we should not require a time-of-day to be present in the input, because we can't represent that in the result type anyway. Rather than trying to decide which specializations should require a time-of-date and which should not, follow the direction of Howard Hinnant's date library, which allows extracting a sys_time of any period from input that only contains a date, defaulting the time-of-day part to 00:00:00. This seems consistent with the intent of the standard, which says it's an error "If the parse fails to decode a valid date" (i.e., it doesn't care about decoding a valid time, only a date). libstdc++-v3/ChangeLog: PR libstdc++/114240 * include/bits/chrono_io.h (_Parser::operator()): Assume hours(0) for a time_point, so that a time is not required to be present. * testsuite/std/time/parse/114240.cc: New test. Diff: --- libstdc++-v3/include/bits/chrono_io.h | 12 ++++++++- libstdc++-v3/testsuite/std/time/parse/114240.cc | 36 +++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/include/bits/chrono_io.h b/libstdc++-v3/include/bits/chrono_io.h index eaa36b8a074..b9eb3d2be53 100644 --- a/libstdc++-v3/include/bits/chrono_io.h +++ b/libstdc++-v3/include/bits/chrono_io.h @@ -3157,6 +3157,16 @@ namespace __detail minutes __tz_offset = __bad_min; basic_string<_CharT, _Traits> __tz_abbr; + if ((_M_need & _ChronoParts::_TimeOfDay) + && (_M_need & _ChronoParts::_Year)) + { + // For time_points assume "00:00:00" is implicitly present, + // so we don't fail to parse if it's not (PR libstdc++/114240). + // We will still fail to parse if there's no year+month+day. + __h = hours(0); + __parts = _ChronoParts::_TimeOfDay; + } + // bool __is_neg = false; // TODO: how is this handled for parsing? _CharT __mod{}; // One of 'E' or 'O' or nul. @@ -4098,7 +4108,7 @@ namespace __detail const bool __need_wday = _M_need & _ChronoParts::_Weekday; // Whether the caller wants _M_sys_days and _M_time. - // Only true for time_points. + // Only true for durations and time_points. const bool __need_time = _M_need & _ChronoParts::_TimeOfDay; if (__need_wday && __wday != __bad_wday) diff --git a/libstdc++-v3/testsuite/std/time/parse/114240.cc b/libstdc++-v3/testsuite/std/time/parse/114240.cc new file mode 100644 index 00000000000..46310efd09a --- /dev/null +++ b/libstdc++-v3/testsuite/std/time/parse/114240.cc @@ -0,0 +1,36 @@ +// { dg-do run { target c++20 } } + +// PR libstdc++/114240 sys_days not being parsed with only a date in the stream + +#include <chrono> +#include <sstream> +#include <testsuite_hooks.h> + +template<class Clock> +void +test_parse_date_only() +{ + using namespace std::chrono; + + using CDays = time_point<Clock, days>; + CDays td; + std::istringstream is("2024-03-05"); + VERIFY( is >> parse("%Y-%m-%d ", td) ); + if constexpr (std::is_same_v<Clock, std::chrono::local_t>) + VERIFY( td == static_cast<local_time<days>>(2024y/March/5) ); + else + { + auto tp = clock_cast<Clock>(sys_days(2024y/March/5)); + VERIFY( td == time_point_cast<days>(tp) ); + } +} + +int main() +{ + test_parse_date_only<std::chrono::system_clock>(); + test_parse_date_only<std::chrono::utc_clock>(); + test_parse_date_only<std::chrono::tai_clock>(); + test_parse_date_only<std::chrono::gps_clock>(); + test_parse_date_only<std::chrono::file_clock>(); + test_parse_date_only<std::chrono::local_t>(); +}
reply other threads:[~2024-03-09 0:29 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240309002934.E7F00385E445@sourceware.org \ --to=redi@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).