On Tue, Apr 27, 2021 at 5:02 PM Peter Brett <pbrett_at_[hidden]> 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,
>
>
>
> Peter
>
>
>
> *From:* SG16 <sg16-bounces_at_[hidden]> *On Behalf Of *Tom Honermann
> via SG16
> *Sent:* 27 April 2021 15:56
> *To:* sg16_at_[hidden]; Marshall Clow <lwgchair_at_[hidden]>
> *Cc:* Tom Honermann <tom_at_[hidden]>; Corentin <
> corentin.jabot_at_[hidden]>
> *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.
>
>
>
> Tom.
>
>
>
> 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
> <https://urldefense.com/v3/__https:/pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap07.html__;!!EHscmS1ygiU1lA!XpEkILFFUIvv-_PAiW563GqpSYRnmF3jvkGOyJ7bccvT2S7cgz_5T49xjGs6vg$>
> )
>
>
>
> Suggested wording
>
>
>
> Modify [time.format]/1
>
>
>
> *chrono-format-spec: *
>
> * 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.
>
>
>
>
>
>
>
>
>
>
>