public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/114260] New: std::formatter<std::chrono::utc_time<std::chrono::days>> formats as the previous day Date: Wed, 06 Mar 2024 23:51:22 +0000 [thread overview] Message-ID: <bug-114260-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260 Bug ID: 114260 Summary: std::formatter<std::chrono::utc_time<std::chrono::days >> formats as the previous day Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- We give surprising output for std::formatter<std::chrono::utc_time<days>>: #include <chrono> #include <iostream> #include <sstream> using namespace std::chrono; int main(){ auto sdays = std::chrono::sys_days(2024y/March/5); auto udays = std::chrono::utc_clock::from_sys(sdays); std::cout << udays << '\n'; std::cout << round<days>(udays) << '\n'; } This prints: 2024-03-05 00:00:00 2024-03-04 23:59:33 This happens because formatter<chrono::utc_time<days>> subtracts leap seconds to get a sys_time (and checks to see whether we need to format the seconds as "60") and then formats that result using formatter<chrono::sys_seconds>. The result has a higher precision than utc_time<days> and is no longer the "correct" day. I think we want to use chrono::round<D> after subtracting leap seconds, to get back to the original resolution. Otherwise we're formatting a sys_time that differs from the supplied utc_time by less than that time's minimum tick. So: --- a/libstdc++-v3/include/bits/chrono_io.h +++ b/libstdc++-v3/include/bits/chrono_io.h @@ -2067,7 +2067,7 @@ namespace __format const auto __li = chrono::get_leap_second_info(__t); sys_time<_CDur> __s{__t.time_since_epoch() - __li.elapsed}; if (!__li.is_leap_second) [[likely]] - return _M_f._M_format(__s, __fc); + return _M_f._M_format(chrono::round<_Duration>(__s), __fc); else return _M_f._M_format(__utc_leap_second(__s), __fc); } Or maybe not even subtract leap seconds at all when the the sum of elapsed leap seconds is less than Duration{1}? If the time being formatted can't represent the number of elapsed leap seconds, is it meaningful to say the time falls within a leap second? For the first ever leap second, yes it is: clock_cast<utc_clock>(sys_days{July/1/1972} - 500ms) + 500ms -> 1972-06-30 23:59:60.000 round<minutes>(clock_cast<utc_clock>(sys_days{July/1/1972} - 500ms) + 500ms) -> 1972-06-30 23:59:60 But for every leap second after that (and all future ones, unless the sum of positive and negative leap seconds becomes a multiple of 60 again) rounding a sys_time to utc_time<minutes> cannot fall within a leap second and so doesn't need to print "60" for the seconds: clock_cast<utc_clock>(sys_days{January/1/1973} - 500ms) + 500ms -> 1972-12-31 23:59:60.000 round<minutes>(clock_cast<utc_clock>(sys_days{January/1/1973} - 500ms) + 500ms) -> 1972-12-31 23:59:59 (with current GCC trunk, so not rounded to minutes) -> 1973-01-01 00:00:00 (with the patch above to round to minutes) The 23:59:59 result is not useful, it's neither a leap second like 23:59:60, nor a round number of minutes like 00:00:00. I think we should format it as 00:00:00, which we could do by not subtracting the leap seconds at all. Maybe we could do: if (auto li = get_leap_second_info(ut); !li.is_leap_second && li.elapsed < Duration{1}) _M_format(sys_time<Duration>(ut.time_since_epoch()), fc); else if (!li.is_leap_second) _M_format(round<Duration>(sys_time<CDur>(ut.time_since_epoch()) - li.elapsed), fc); else // ... But I don't think that's necessary, just round<Duration> should give the desired result. Avoiding the subtraction doesn't seem like a useful optimization (especially as we'd still have done the much slower get_leap_second_info lookup anyway). CC Howard to check I'm not talking nonsense.
next reply other threads:[~2024-03-06 23:51 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-06 23:51 redi at gcc dot gnu.org [this message] 2024-03-07 8:18 ` [Bug libstdc++/114260] " redi at gcc dot gnu.org 2024-03-07 22:44 ` howard.hinnant at gmail dot com 2024-03-07 23:08 ` redi at gcc dot gnu.org
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=bug-114260-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).