Fix handling of locale in chrono formatters

[Victor Zverovich (vitaut)]

Make chrono formatting locale-independent by default and add the L specifier for consistency with all other standard formatters. Resolves https://cplusplus.github.io/LWG/issue3547 and #1891.

For example:

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));
  std::cout << std::format("{:L%S}\n", std::chrono::milliseconds(42));
}
C:\test>test
0.042
00.042
00,042

[Michael Schellenberger Costa (miscco)]

How about you put a test on it

[Charlie Barto (barcharcraz)]

Needs tests, and also probably needs ABI mitigations (that would involve changing mangled names).

Also I don't want to merge this before the LWG issue is approved, it's somewhat of a design change and I'm not sure LWG will adopt the issue.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks! Aside from ABI renaming and stylistic nitpicks, this looks good to me.

[Victor Zverovich (vitaut)]

Switched ostream insertion operators back to using locale per LEWG request and implemented two drive-by fixes:

1. Use the correct locale when formatting utc_time and similar types (previously the global locale was used).
2. Use the correct locale when chrono specs are omitted (also the global locale was used).

Also added tests for insertion operators. Note that item 1 is currently untestable (there is no observable change) because %T is broken - it ignores the fractional part of the seconds component. Fixing %T is out of scope of this PR.

[Charlie Barto (barcharcraz)]

We can't merge this until the paper has been forwarded out of LWG, however we're happy to keep the PR open and continue reviewing changes.

[Stephan T. Lavavej (StephanTLavavej)]

Here's hoping that this paper gets through LWG swiftly 😸

[Stephan T. Lavavej (StephanTLavavej)]

The paper has been voted into the WP: #2237

[Victor Zverovich (vitaut)]

I don't plan to work on this PR (although it should be mostly ready), hopefully someone will take over.

[Charlie Barto (barcharcraz)]

I'll get this past the finish line now that it's been voted in.

Are you OK with just reopening this PR (and me pushing into it) or do you want to avoid github notifications and have me pick out the commits into a new PR.

[Victor Zverovich (vitaut)]

Unfortunately I already removed the repo this PR originated from so I can't reopen. Please create a new PR.