On 4/28/21 3:13 PM, Victor Zverovich wrote:
> FWIW I took a stab at implementing the 'L' specifier for chrono
> durations in
> https://github.com/fmtlib/fmt/commit/652b797ebcac29493f1a3216323db823a3b162bb.
>
>
> With this change
>
> #include <fmt/chrono.h>
> #include <iostream>
>
> int main() {
> std::locale::global(std::locale("ja_JP.utf8"));
> std::cout << fmt::format("{:%r}", std::chrono::hours(14)) << "\n";
> std::cout << fmt::format("{:L%r}", std::chrono::hours(14)) << "\n";
> }
>
> gives the following output:
>
> 02:00:00 PM
> 午後02時00分00秒

I am not well trained in Japanese, but I am reasonably well trained in
mojibake and that doesn't look like mojibake! 🥳🎉

Tom.

>
> Cheers,
> Victor
>
>
> On Wed, Apr 28, 2021 at 11:26 AM Tom Honermann via SG16
> <sg16_at_[hidden] <mailto:sg16_at_[hidden]>> wrote:
>
> 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.
>>>
>>>
>>
>>
>
> --
> SG16 mailing list
> SG16_at_[hidden] <mailto:SG16_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>