Corentin submitted a LWG issue for the concern about std::format() using
the locale for chrono format specifiers. We'll address this first and
then continue discussion of P2093.

  * LWG3547: Time formatters should not be locale sensitive by default
    <https://cplusplus.github.io/LWG/lwg-active.html#3547>

Tom.

On 4/27/21 11:58 AM, Tom Honermann via SG16 wrote:
> Despite this message likely getting lost in the flurry of messages
> within this email thread over the last 12 hours or so, here is your
> reminder that this telecon will be taking place tomorrow.
>
> Corentin submitted a revision of P2295 <https://wg21.link/p2295r3>
> with wording updates intended to address feedback from our last
> telecon
> <https://github.com/sg16-unicode/sg16-meetings#april-14th-2021>. So,
> if time permits after discussion of P2093R5
> <https://wg21.link/p2093r5>, then we'll revisit it. Otherwise, it
> will be the first item on the agenda for the following telecon. I
> expect that we won't get to P2348R0 <https://wg21.link/p2348r0>.
>
> Revised agenda:
>
> * P2093R5: Formatted output <https://wg21.link/p2093r5>
> * P2295R3: Support for UTF-8 as a portable source file encoding
> <https://wg21.link/p2295r3>
> * P2348R0: Whitespaces Wording Revamp <https://wg21.link/p2348r0>
>
> Tom.
>
> On 4/19/21 10:58 AM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a telecon on Wednesday, April 28th at 19:30 UTC
>> (timezone conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20210428T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>>
>> The agenda is:
>>
>> * P2093R5: Formatted output <https://wg21.link/p2093r5>
>> * P2348R0: Whitespaces Wording Revamp
>> <https://isocpp.org/files/papers/P2348R0.pdf>
>>
>> LEWG discussed P2093R5 at their 2021-04-06 telecon and decided to
>> refer the paper back to SG16 for further discussion. LEWG meeting
>> minutes are available here
>> <https://wiki.edg.com/bin/view/Wg21telecons2021/P2093#Library-Evolution-2021-04-06>;
>> please review them prior to the telecon. LEWG reviewed the list of
>> prior SG16 deferred questions posted to them here
>> <http://lists.isocpp.org/lib-ext/2021/03/18189.php>. Of those, they
>> established consensus on an answer for #2 (they agreed not to block
>> std::print() on a proposal for underlying terminal facilities), but
>> referred the rest back to us. My interpretation of their actions is
>> that LEWG would like a revision of the paper to address these
>> concerns based on SG16 input (e.g., discuss design options and SG16
>> consensus or lack thereof). We'll therefore focus on these questions
>> at this telecon.
>>
>> Hubert provided the following very interesting example usage.
>>
>> std::print("{:%r}\n",
>> std::chrono::system_clock::now().time_since_epoch());
>>
>> At issue is the encoding used by locale sensitive chrono formatters.
>> Search [time.format] <http://eel.is/c++draft/time.format> for
>> "locale" to find example chrono format specifiers that are locale
>> dependent. The example above contains the %r specifier and is locale
>> sensitive because AM/PM designations may be localized. In a Chinese
>> locale the desired translation of "PM" is "下午", but the locale will
>> provide the translation in the locale encoding. As specified in
>> P2093R5, if the execution (literal) encoding is UTF-8, than
>> std::print() will expect the translation to be provided in UTF-8, but
>> if the locale is not UTF-8-based (e.g., Big5; perhaps Shift-JIS for
>> the Japanese 午後 translation), then the result is mojibake. This is a
>> good example of how locale conflates translation and character encoding.
>>
>> Addressing the above will be our first order of business. Please
>> reserve some time to independently think about this problem (ignore
>> responses to this message for a few days if you need to). I am
>> explicitly not listing possible approaches to address this concern in
>> this message so as to avoid adding (further) bias in any specific
>> direction. I suspect the answers to the previously deferred SG16
>> questions will be easier to answer once this concern is resolved.
>>
>> I do not intend to time limit discussion of P2093R5 as I believe this
>> is an important matter to resolve. If we are able to complete
>> discussion of P2093R5, then we'll discuss P2348R0.
>>
>> Tom.
>>
>>
>
>