On Thu, Jun 17, 2021 at 10:57 PM Peter Brett via SG16 <sg16@lists.isocpp.org> wrote:
Hi all,

The current proposed resolution for LWG3565 (https://wg21.link/LWG3565)
involves transcoding from the locale encoding to UTF-8.  This makes me a
little uncomfortable.

Can you clarify what makes you uncomfortable?

Is it possible instead to say that, if the string literal encoding is
UTF-8, then the effective locale is _as if_ the specified or global
locale was modified by replacing the associated codeset with UTF-8?

So, the following code:

    std::locale l1("Russian.1251");
    auto s = std::format(l1, "День недели: {:L}", std::chrono::Monday);

Would behave as if replaced by:

    std::locale l1("Russian.1251");
    std::locale l2(l1, std::locale("Russian.UTF-8"), locale::time);
    auto s = std::format(l2, "День недели: {:L}", std::chrono::Monday);

This would permit an implementation that has UTF-8 locale data available
to use it directly, rather than being required to use the 1251 codeset
locale data and transcode in order to conform to the standard.

"associated codeset with UTF-8" is not really a thing.
The ".UTF-8" locales merely exist by convention on some platforms 

There is no spec that says that

* Russian.1251 is not UTF-8
* Russian.1251.UTF-8 exists
* Russian.1251 and Russian.1251.UTF-8 only differ by encoding if both exist

Transcoding is therefore more generally applicable.

Note that I have my own reservations about this issue, namely how much effort are we willing to put
into mending a system that only works for a narrow subset of cultures, languages and circumstances?
That being said, even if that issue amounts to putting duct tape over a giant crack in the wall,
It also doesn't hurt.
It is undoubtedly more correct than the status quo and it might make the life of our windows users a bit less painful
as a stopgap solution


P.S. How would one go about writing a locale object that customizes
chrono formatting with std::format?  Does anyone have a code sample?
SG16 mailing list