From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 7CCA83858408; Fri, 19 Jan 2024 13:09:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CCA83858408
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705669759;
	bh=4tz7WUxf0K9hx7RlACpBXw+rR3T5wQZjl993z3SFODY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jGHgT29uw7xV1kYo6XKNIGWWH1AwQXadomCbv4pQUHCPH1AFEYtctCQroAWp+9cAQ
	 YJTgK5xoDi81mR8d5Zt6GF3u4FqhJCxvOwXo6e2MDYnyn6fSb2cl5NlBqCdP+VcXXL
	 shoxsJUm5SaOlWJCnjWLUeMyf2ak8enUK64CeAmE=
From: "Hirthammer@allterra-dno.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/113500] Using std::format with float or double based
 std::chrono::time_point causes error: no match for 'operator<<'
Date: Fri, 19 Jan 2024 13:09:19 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Hirthammer@allterra-dno.de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113500-4-Qd2PNuR1td@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113500-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113500-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113500

--- Comment #5 from Hirthammer@allterra-dno.de ---
(In reply to Jonathan Wakely from comment #4)
> MSVC rejects this the same way, although libc++ from LLVM 17 compiles it.
>=20
> AFAICT std::format("{}", tp) would be invalid because that formats tp by
> writing to a stream, and there is no operator<< for
> sys_time<duration<floating-point>>.
>=20
> Arguably, std::format("{:%S}", tp) could work, because it doesn't need to
> use operator<< but the problem is that we can't detect at compile-time
> whether or not we need to use operator<< for a given format string. So it
> always fails to compile.
>=20
> The reason it works with libc++ is because they have a bug in their
> operator<< for sys_time.
>=20
> I think libstdc++ is correct here, but I've asked the C++ committee wheth=
er
> we might want to change the standard to support this case.

This whole thing with std::format and std::chrono::time_point is currently a
total minefield. In MSVC it is even more complicated and I already reported=
 the
bug in October 2023. See:

https://developercommunity.visualstudio.com/t/Using-std::format-with-unsign=
ed-integer-/10501153

If you change the clock to utc_clock or gps_clock the code compiles with MS=
VC
(but not with GCC) on Compiler Explorer.

I don't know much about the exact definitions of the standard. But I find it
very confusing if std::format generally supports a std::chrono::time_point =
as
an input, but depending on the chosen template arguments of the time_point =
it
does or does not compile.=