D2372R1: Fixing locale handling in chrono formatters

[vitaut]

Describe the bug

Chrono formatting depends on locale by default and doesn't provide control over locale which is inconsistent with all the other standard formatters (https://cplusplus.github.io/LWG/issue3547).

Command-line test case

C:\test>type test.cc
#include <chrono>
#include <format>
#include <iostream>

int main() {
  std::locale::global(std::locale("ru_RU"));
  std::cout << std::format("{}\n", 0.042);
  std::cout << std::format("{:%S}\n", std::chrono::milliseconds(42));
}

C:\test>cl test.cc /std:c++latest /I STL/stl/inc STL/stl/src/format.cpp /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.29917 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

cl : Command line warning D9026 : options apply to entire command line
test.cc
format.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 14.29.29917.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj
format.obj

C:\test>test
0.042
00,042

Expected behavior

Expected the output to be

0.042
00.042

i.e. not depend on the locale.

STL version

f675d68

[barcharcraz]

While this is a problem, it's a problem in the standard, not a bug in our implementation.

I've renamed the issue to reflect what I think is the latest paper number addressing this. (It's somewhat unlikely the LWG issue will be adopted)

[StephanTLavavej]

@barcharcraz Note, I have removed the cxx23 label as that denotes accepted C++23 papers. If and when this paper is voted in, we should create a cxx23-labeled issue tracking the final revision. This label affects the Status Chart (see screenshot), and so does the time of issue creation - so when this paper is voted in, we should create a fresh issue to track that.

No objections to keeping this issue with the "LEWG issue needed" etc. labels.

[ghost]

Excuse me, does #2273 (P2372R3) solved this issue?

[CaseyCarter]

Excuse me, does #2273 (P2372R3) solved this issue?

LWG-3547 certainly seems to think it does. @barcharcraz, is there anything else to do here, or shall we consider this issue fixed?

[StephanTLavavej]

+1 for closing this as fixed (and superseded by issue #2237, which amusingly is a digit transposition of the PR #2273).