https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500
--- Comment #11 from hirtham...@allterra-dno.de --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #6) > > (In reply to Hirthammer from comment #5) > > > This whole thing with std::format and std::chrono::time_point is > > > currently a > > > total minefield. > > > > That seems like an exaggeration. > > > > > 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- > > > unsigned-integer-/10501153 > > > > > > If you change the clock to utc_clock or gps_clock the code compiles with > > > MSVC (but not with GCC) on Compiler Explorer. > > > > It compiles fine with GCC for me. > > Ah, maybe you mean your original example. The one at in the MSVC bug report > compiles fine with GCC using utc_clock and gps_clock. > > Your original example doesn't, because formatting a utc_time or gps_time is > specified in terms of a sys_time, and that's how libstdc++ implements it. So > if the utc_time or gps_time uses a float rep, we're back to square one. > > I'll ask the committee to clarify that too. Yes, I was referring to my original example because it helped me to understand which combinations worked and which did not. I wrote a wrapper class around std::chrono::time_point, because I am dealing a lot with different time formats. I am also doing multi-platform development, and during the testing phase, it turned out that no compiler was able to compile all templated test cases (Clang uses libstdc++ if you do not explicitly tell it not to do, as you pointed out on the llvm bug report). Since the error case parameter combinations differed from MSVC and GCC, I had to use many different compiler-specific sections to get consistent and valid behavior in the tests. That's why I called it a minefield. Maybe it was exaggerated ;). Anyways, thank you a lot for your effort and clarifications and especially for the fast fix.
