On Tue, Apr 27, 2021 at 5:02 PM Peter Brett <pbrett@cadence.com> wrote:

Hi all,


Thank you to Corentin for raising this library issue. I think this a very clear design bug in the std::chrono formatter that we should have spotted during NB review of C++20.


I feel that *fixing* this design bug is going to be pretty challenging, especially given the ABI implications for any code that uses C++20 std::format to format times.

That is exactly 0 line of code right now - although that will change very soon.
I don't *think* it has an ABI impact but it does change the meaning of code.
TL;DR: we need to act fast if we want to act at all - If we agree on a resolution, notifying the microsoft devs sooner rather than later will avoid surprises. 


However, I also think that this helps to clarify that the concerns raised about the use of the std::chrono formatter with std::print does *not* indicate a problem with the design of std::print.  If we have issues with the design of std::print, then I recommend that we focus on problems that arise from using other standard formatters (if any).


Best regards,




From: SG16 <sg16-bounces@lists.isocpp.org> On Behalf Of Tom Honermann via SG16
Sent: 27 April 2021 15:56
To: sg16@lists.isocpp.org; Marshall Clow <lwgchair@gmail.com>
Cc: Tom Honermann <tom@honermann.net>; Corentin <corentin.jabot@gmail.com>
Subject: Re: [SG16] LWG issue: Time formatters should not be locale sensitive by default


I agree with this direction, though perhaps we should simply drop locale support until we're ready to make it work in an encoding correct manner.




On 4/27/21 3:29 AM, Corentin via SG16 wrote:

In [time.format], it is specified 


> Some of the conversion specifiers depend on the locale that is passed to the formatting function if the latter takes one, or the global locale otherwise


This is not consistent with the format design after the adoption of P1892

In [format.string.std] we say:


> When the L option is used, the form used for the conversion is called the locale-specific form. The L option is only valid for arithmetic types, and its effect depends upon the type


This has 2 issues:

First, it is inconsistent.


format("{}, 0.0"); // locale independent
format("{:L}", 0.0); // use locale
format("{:%r}, some_time); // use globale locale

format("{:%rL}, some_time); // error


And second it perpetuates the issues P1892 intended to solve.

It is likely that this inconsistency resulted from both papers being in flight around the same time


Proposed resolution


The L option should be used and consistent with floating point. We suggest using the C locale which is the non-locale locale. (https://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap07.html)


Suggested wording


Modify [time.format]/1



    fill-and-align(opt) width(opt) precision(opt) chrono-specs(opt)L(opt)


Modify [time.format]/2


Each conversion specifier conversion-spec is replaced by appropriate characters as described in Table 101; the formats specified in ISO 8601:2004 shall be used where so described. Some of the conversion specifiers depend on <del>the locale that is passed to the formatting function if the latter takes one, or the global locale otherwise</del>

<ins>a locale. If the L option is used, that locale is the locale that is passed to the formatting function if the later takes one, or the global locale otherwise. If the L option is not used, that locale is the "C" locale</ins>.If the formatted object does not contain the information the conversion specifier refers to, an exception of type format_error is thrown.