On Wed, Apr 28, 2021 at 8:26 PM Tom Honermann via SG16 <
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.
>

Thanks Tom for staying on top of things :)


> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>