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.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 with wording updates intended to address feedback from our last telecon. So, if time permits after discussion of 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.
Revised agenda: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).
The agenda is:
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; please review them prior to the telecon. LEWG reviewed the list of prior SG16 deferred questions posted to them here. 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] 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16