<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/7/19 11:23 AM, Billy O'Neal (VC
      LIBS) wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:MW2PR2101MB1098EE3C28C0BBBFECE68E3DCB780@MW2PR2101MB1098.namprd21.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:"Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
      <div class="WordSection1">
        <p>&gt; The library doesn't need to assume.  An example
          implementation (ignoring support for non-char types) could be:
          […]</p>
        <p class="MsoNormal">That does not do the correct thing because
          the locale on the target is often not the locale when
          compiling. At compile time we usually consider our ‘execution
          character set’ to be the ASCII subset for maximum resistance
          to changes in locale at runtime, but the compiler will
          generally pass through more strict settings if the user has
          set them.</p>
      </div>
    </blockquote>
    This is exactly why the original wording I proposed stated that the
    result is unspecified if the run-time locale encoding is not
    compatible with the encoding used for the execution character set.<br>
    <blockquote type="cite"
cite="mid:MW2PR2101MB1098EE3C28C0BBBFECE68E3DCB780@MW2PR2101MB1098.namprd21.prod.outlook.com">
      <div class="WordSection1">
        <p>&gt; I think the Windows 10 comment is only relevant with
          respect to the run-time locale and choice of encoding for the
          console/terminal.  Execution character set is independent of
          both of those.<o:p></o:p></p>
        <p class="MsoNormal">It is dependent with both of those in that
          the choice of execution character set is constrained by the
          environment in which the program will run.</p>
      </div>
    </blockquote>
    <p>Indeed.  But if a programmer compiles their code with
      /execution-charset:utf-8, it seems a clear indication that they
      intend to constrain the environment in which the program is run to
      one that supports UTF-8 (e.g., Windows 10, with UTF-8 ACP, and the
      new Windows Terminal).  I recognize that such a deployment target
      is an uncommon reality today, but that is a direction to be
      encouraged.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:MW2PR2101MB1098EE3C28C0BBBFECE68E3DCB780@MW2PR2101MB1098.namprd21.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Billy3</p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <hr style="display:inline-block;width:98%" tabindex="-1">
      <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
          color="#000000" face="Calibri, sans-serif"><b>From:</b> Tom
          Honermann <a class="moz-txt-link-rfc2396E" href="mailto:tom@honermann.net">&lt;tom@honermann.net&gt;</a><br>
          <b>Sent:</b> Wednesday, November 6, 2019 10:58:17 PM<br>
          <b>To:</b> Billy O'Neal (VC LIBS) <a class="moz-txt-link-rfc2396E" href="mailto:bion@microsoft.com">&lt;bion@microsoft.com&gt;</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:lib@lists.isocpp.org">lib@lists.isocpp.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:lib@lists.isocpp.org">&lt;lib@lists.isocpp.org&gt;</a>; Corentin
          <a class="moz-txt-link-rfc2396E" href="mailto:corentin.jabot@gmail.com">&lt;corentin.jabot@gmail.com&gt;</a><br>
          <b>Cc:</b> C++ Library Evolution Working Group
          <a class="moz-txt-link-rfc2396E" href="mailto:lib-ext@lists.isocpp.org">&lt;lib-ext@lists.isocpp.org&gt;</a>; <a class="moz-txt-link-abbreviated" href="mailto:unicode@isocpp.open-std.org">unicode@isocpp.open-std.org</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:unicode@open-std.org">&lt;unicode@open-std.org&gt;</a><br>
          <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
          [isocpp-lib-ext] [time.duration.io] : Is stream insertion
          behavior locale dependent when Period::type is micro?</font>
        <div> </div>
      </div>
      <div style="background-color:#FFFFFF">
        <div class="x_moz-cite-prefix">On 11/6/19 10:20 PM, Billy O'Neal
          (VC LIBS) wrote:<br>
        </div>
        <blockquote type="cite">
          <meta name="Generator" content="Microsoft Word 15 (filtered
            medium)">
          <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
@font-face
        {}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext}
.x_MsoChpDefault
        {}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
        {}
-->
</style>
          <div class="x_WordSection1">
            <p>&gt; That isn't what it (is intended to) say, nor how I
              read it. </p>
            <p>Then remove the qualifications about terminals or codecvt
              facets and talk only about the execution character set,
              and things are OK. (As Corentin’s PR does)</p>
            <p>&gt; The intent of the wording was to allow Microsoft to
              use "µs" when the compiler is invoked with
              /execution-charset:utf-8 and to use "us" otherwise.</p>
            <p class="x_MsoNormal">Given that UTF-8 support is still a
              rarely used user opt-in at this time only available on
              recent versions of Windows 10, it isn’t an assumption the
              library is going to be able to make soon (i.e. the next
              decade)</p>
          </div>
        </blockquote>
        <p>The library doesn't need to assume.  An example
          implementation (ignoring support for non-char types) could be:<br>
        </p>
        <pre>template&lt;class traits, class Rep, class Period&gt;<tt>
void print_fancy_suffix</tt><tt>(basic_ostream&lt;char, traits&gt;&amp; os, const duration&lt;Rep, Period&gt;&amp; d)</tt><tt>
{</tt><tt>
  static const char micro_sign[] = "\u00B5s";</tt><tt>
  if (as_unsigned(micro_sign[0]) == 0xC2</tt><tt>u &amp;&amp;</tt><tt>
      as_unsigned(micro_sign[1]) == 0xB5u)</tt><tt>
  {</tt><tt>
    // execution character set smells like UTF-8.</tt><tt>
    os &lt;&lt; </tt><tt>d.count() &lt;&lt; micro_sign;</tt><tt>
  } else {</tt><tt>
    // execution character set smells like bad.</tt><tt>
    </tt><tt><tt>os &lt;&lt; </tt><tt>d.count() &lt;&lt; "us";</tt></tt><tt>
  }</tt><tt>
}</tt>
</pre>
        <p>There are, of course, better ways to do this if the compiler
          has the ability to inform the library what the execution
          character set really is (e.g., a predefined macro).</p>
        <p>I'm not arguing for any particular choice on Microsoft's
          part.<br>
        </p>
        <p>I think the Windows 10 comment is only relevant with respect
          to the run-time locale and choice of encoding for the
          console/terminal.  Execution character set is independent of
          both of those.<br>
        </p>
        <p>Tom.<br>
        </p>
        <blockquote type="cite">
          <div class="x_WordSection1">
            <p class="x_MsoNormal"> </p>
            <p class="x_MsoNormal">Billy3</p>
            <p class="x_MsoNormal"> </p>
          </div>
          <hr tabindex="-1" style="display:inline-block; width:98%">
          <div id="x_divRplyFwdMsg" dir="ltr"><font
              style="font-size:11pt" color="#000000" face="Calibri,
              sans-serif"><b>From:</b> Tom Honermann
              <a class="x_moz-txt-link-rfc2396E"
                href="mailto:tom@honermann.net" moz-do-not-send="true">&lt;tom@honermann.net&gt;</a><br>
              <b>Sent:</b> Wednesday, November 6, 2019 5:38:34 PM<br>
              <b>To:</b> Billy O'Neal (VC LIBS) <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:bion@microsoft.com" moz-do-not-send="true">
                &lt;bion@microsoft.com&gt;</a>; <a
                class="x_moz-txt-link-abbreviated"
                href="mailto:lib@lists.isocpp.org"
                moz-do-not-send="true">
                lib@lists.isocpp.org</a> <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:lib@lists.isocpp.org"
                moz-do-not-send="true">
                &lt;lib@lists.isocpp.org&gt;</a>; Corentin <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:corentin.jabot@gmail.com"
                moz-do-not-send="true">
                &lt;corentin.jabot@gmail.com&gt;</a><br>
              <b>Cc:</b> C++ Library Evolution Working Group <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:lib-ext@lists.isocpp.org"
                moz-do-not-send="true">
                &lt;lib-ext@lists.isocpp.org&gt;</a>; <a
                class="x_moz-txt-link-abbreviated"
                href="mailto:unicode@isocpp.open-std.org"
                moz-do-not-send="true">
                unicode@isocpp.open-std.org</a> <a
                class="x_moz-txt-link-rfc2396E"
                href="mailto:unicode@open-std.org"
                moz-do-not-send="true">
                &lt;unicode@open-std.org&gt;</a><br>
              <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
              [isocpp-lib-ext] [time.duration.io] : Is stream insertion
              behavior locale dependent when Period::type is micro?</font>
            <div> </div>
          </div>
          <div style="background-color:#FFFFFF">
            <div class="x_x_moz-cite-prefix">On 11/6/19 5:30 PM, Billy
              O'Neal (VC LIBS) wrote:<br>
            </div>
            <blockquote type="cite">
              <meta name="Generator" content="Microsoft Word 15
                (filtered medium)">
              <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
p.x_x_MsoNormal, li.x_x_MsoNormal, div.x_x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
-->
</style>
              <div class="x_x_WordSection1">
                <p class="x_x_MsoNormal">Corentin’s PR says “if char
                  (the execution encoding) can always represent µ for
                  your implementation, use that. Otherwise use u.” Which
                  means on my implementation where char can’t always
                  represent such a thing as that is locale dependent. we
                  will statically use u (and µ for wchar_t); but an
                  implementation that assumes char is UTF-8 could use µ.<br>
                  <br>
                </p>
                <p class="x_x_MsoNormal">The LWG issue’s PR says “if the
                  stream can detect that it is targeting a console or
                  codecvt facet that don’t support µ, an implementation 
                  may use u, otherwise they use µ”. But streams have no
                  means of doing that detection. (And the answer can
                  even change if someone changes the streambuf)</p>
              </div>
            </blockquote>
            <p>That isn't what it (is intended to) say, nor how I read
              it.  It states that the suffix is determined by the
              execution character set (the character set used for string
              literals and known at compile time); that is in the first
              sentence.  The second sentence acknowledges that if the
              native character set (the run-time locale dependent
              character set) lacks representation for the character,
              then all bets are off with regard to how the character is
              actually displayed (or converted by a codecvt facet).</p>
            <p>The intent of the wording was to allow Microsoft to use
              "µs" when the compiler is invoked with
              /execution-charset:utf-8 and to use "us" otherwise.<br>
            </p>
            <p>Tom.<br>
            </p>
            <blockquote type="cite">
              <div class="x_x_WordSection1">
                <p class="x_x_MsoNormal"> </p>
                <p class="x_x_MsoNormal">Billy3</p>
                <p class="x_x_MsoNormal"> </p>
              </div>
              <hr tabindex="-1" style="display:inline-block; width:98%">
              <div id="x_x_divRplyFwdMsg" dir="ltr"><font
                  style="font-size:11pt" color="#000000" face="Calibri,
                  sans-serif"><b>From:</b> Tom Honermann
                  <a class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:tom@honermann.net"
                    moz-do-not-send="true">&lt;tom@honermann.net&gt;</a><br>
                  <b>Sent:</b> Wednesday, November 6, 2019 5:14:18 PM<br>
                  <b>To:</b> Billy O'Neal (VC LIBS) <a
                    class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:bion@microsoft.com"
                    moz-do-not-send="true">
                    &lt;bion@microsoft.com&gt;</a>; <a
                    class="x_x_moz-txt-link-abbreviated"
                    href="mailto:lib@lists.isocpp.org"
                    moz-do-not-send="true">
                    lib@lists.isocpp.org</a> <a
                    class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:lib@lists.isocpp.org"
                    moz-do-not-send="true">
                    &lt;lib@lists.isocpp.org&gt;</a>; Corentin <a
                    class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:corentin.jabot@gmail.com"
                    moz-do-not-send="true">
                    &lt;corentin.jabot@gmail.com&gt;</a><br>
                  <b>Cc:</b> C++ Library Evolution Working Group <a
                    class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:lib-ext@lists.isocpp.org"
                    moz-do-not-send="true">
                    &lt;lib-ext@lists.isocpp.org&gt;</a>; <a
                    class="x_x_moz-txt-link-abbreviated"
                    href="mailto:unicode@isocpp.open-std.org"
                    moz-do-not-send="true">
                    unicode@isocpp.open-std.org</a> <a
                    class="x_x_moz-txt-link-rfc2396E"
                    href="mailto:unicode@open-std.org"
                    moz-do-not-send="true">
                    &lt;unicode@open-std.org&gt;</a><br>
                  <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
                  [isocpp-lib-ext] [time.duration.io] : Is stream
                  insertion behavior locale dependent when Period::type
                  is micro?</font>
                <div> </div>
              </div>
              <div style="background-color:#FFFFFF">
                <div class="x_x_x_moz-cite-prefix">On 11/6/19 4:30 PM,
                  Billy O'Neal (VC LIBS) wrote:<br>
                </div>
                <blockquote type="cite">
                  <meta name="Generator" content="Microsoft Word 15
                    (filtered medium)">
                  <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
p.x_x_x_MsoNormal, li.x_x_x_MsoNormal, div.x_x_x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
a:link, span.x_x_x_MsoHyperlink
        {color:blue;
        text-decoration:underline}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
-->
</style>
                  <div class="x_x_x_WordSection1">
                    <p class="x_x_x_MsoNormal"
                      style="margin-bottom:12.0pt">&gt; Please read the
                      wording again. Note that it says that, if those
                      conditions are true, then the result is
                      unspecified. </p>
                    <p class="x_x_x_MsoNormal">If “the wording” means
                      the P/R of <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033889953&amp;sdata=gfv7uzxwY5Ol8guxD0C179G6xnDBcdbt2qA%2FVrE3AyU%3D&amp;reserved=0"
originalsrc="https://cplusplus.github.io/LWG/issue3314"
shash="g6iHpX12EKmR/MGRP1Fd5iiSyaBSaQxxHx0G5lcY3BGPY6+3iqrYNlsfRhe+oljJ8eukzqpXI5rIpymiX62kMTB/KkHLcyj0Rm9VbM8LaHSsosk2Qa12P5YvhOWJ2Zf6Ux+0QI0V15dSIg/V7ND/Rt82YnyXUs7Em0RWOKt0U0Y="
                        moz-do-not-send="true">
                        https://cplusplus.github.io/LWG/issue3314</a>,
                      the wording there implies that we must make some
                      effort to determine that the condition is true,
                      which in practice we cannot do because the
                      interface between streams and streambufs is
                      public.</p>
                  </div>
                </blockquote>
                <p>Yes, that is the wording I meant.  The intent is to
                  ensure the implementation does *not* have to put forth
                  such effort.  I don't understand where such an
                  implication is coming from, but that wording has
                  confused at least three experienced wordsmiths, so I
                  acknowledge there is an issue, but I don't understand
                  what it is.<br>
                </p>
                <p>I think it is important to say something here. 
                  Otherwise, one could claim that the terminal failing
                  to display
                  <tt>"μs"</tt> because it is configured for an
                  incompatible encoding is non-conforming.  Well, to the
                  extent that the standard addresses such devices.<br>
                </p>
                <p>Tom.<br>
                </p>
                <blockquote type="cite">
                  <div class="x_x_x_WordSection1">
                    <p class="x_x_x_MsoNormal"> </p>
                    <p class="x_x_x_MsoNormal">Corentin’s P/R below
                      seems to not have this concern.</p>
                    <p class="x_x_x_MsoNormal"> </p>
                    <p class="x_x_x_MsoNormal">Billy3</p>
                    <p class="x_x_x_MsoNormal"> </p>
                  </div>
                  <hr tabindex="-1" style="display:inline-block;
                    width:98%">
                  <div id="x_x_x_divRplyFwdMsg" dir="ltr"><font
                      style="font-size:11pt" color="#000000"
                      face="Calibri, sans-serif"><b>From:</b> Lib
                      <a class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:lib-bounces@lists.isocpp.org"
                        moz-do-not-send="true">
                        &lt;lib-bounces@lists.isocpp.org&gt;</a> on
                      behalf of Tom Honermann via Lib <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:lib@lists.isocpp.org"
                        moz-do-not-send="true">
                        &lt;lib@lists.isocpp.org&gt;</a><br>
                      <b>Sent:</b> Wednesday, November 6, 2019 1:12:48
                      PM<br>
                      <b>To:</b> Corentin <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:corentin.jabot@gmail.com"
                        moz-do-not-send="true">
                        &lt;corentin.jabot@gmail.com&gt;</a><br>
                      <b>Cc:</b> Tom Honermann <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:tom@honermann.net"
                        moz-do-not-send="true">
                        &lt;tom@honermann.net&gt;</a>; C++ Library
                      Evolution Working Group <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:lib-ext@lists.isocpp.org"
                        moz-do-not-send="true">
                        &lt;lib-ext@lists.isocpp.org&gt;</a>; Library
                      Working Group <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:lib@lists.isocpp.org"
                        moz-do-not-send="true">
                        &lt;lib@lists.isocpp.org&gt;</a>; <a
                        class="x_x_x_moz-txt-link-abbreviated"
                        href="mailto:unicode@isocpp.open-std.org"
                        moz-do-not-send="true">
                        unicode@isocpp.open-std.org</a> <a
                        class="x_x_x_moz-txt-link-rfc2396E"
                        href="mailto:unicode@open-std.org"
                        moz-do-not-send="true">
                        &lt;unicode@open-std.org&gt;</a><br>
                      <b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
                      [isocpp-lib-ext] [time.duration.io] : Is stream
                      insertion behavior locale dependent when
                      Period::type is micro?</font>
                    <div> </div>
                  </div>
                  <div dir="auto">The intent of the wording is to say
                    that implementors do *not* need to be aware of
                    terminals or codecvt facets. Without this, the
                    wording could be read that implementations must
                    implement magic to make the character display
                    correctly. 
                    <div><br>
                    </div>
                    <div>Please read the wording again. Note that it
                      says that, if those conditions are true, then the
                      result is unspecified. <br>
                      <br>
                      <div id="x_x_x_x_AppleMailSignature" dir="ltr">Tom.</div>
                      <div dir="ltr"><br>
                        On Nov 6, 2019, at 12:07 PM, Corentin &lt;<a
                          href="mailto:corentin.jabot@gmail.com"
                          moz-do-not-send="true">corentin.jabot@gmail.com</a>&gt;
                        wrote:<br>
                        <br>
                      </div>
                      <blockquote type="cite">
                        <div dir="ltr">
                          <div dir="ltr">Then I would just say
                            associated execution encoding with charT
                            <div><br>
                            </div>
                            <div>Extremely uncomfortable with involving
                              stream, console or anything else not known
                              at compile time  </div>
                          </div>
                          <br>
                          <div class="x_x_x_x_gmail_quote">
                            <div dir="ltr" class="x_x_x_x_gmail_attr">On
                              Wed, 6 Nov 2019 at 04:51, Tom Honermann
                              &lt;<a href="mailto:tom@honermann.net"
                                moz-do-not-send="true">tom@honermann.net</a>&gt;
                              wrote:<br>
                            </div>
                            <blockquote class="x_x_x_x_gmail_quote"
                              style="margin:0px 0px 0px 0.8ex;
                              border-left:1px solid rgb(204,204,204);
                              padding-left:1ex">
                              <div bgcolor="#FFFFFF">On 11/6/19 8:30 AM,
                                Howard Hinnant wrote:<br>
                                <blockquote type="cite">
                                  <pre>You can comment the LWG issue (if you want) by emailing said comment to <a href="mailto:lwgchair@gmail.com" target="_blank" moz-do-not-send="true">lwgchair@gmail.com</a>, specifying which issue you wish to comment and supplying the comment.

Howard

On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
</pre>
                                  <blockquote type="cite">
                                    <pre>Not sure how to do that proceduraly but here is some alternative wording.
The "runtime" locale-tied encoding is *assumed to be* a super set of the execution encoding - to the extent the standard doesn't distinguish between the two


If Period::type is micro, but the &lt;ins&gt;abstract&lt;/ins&gt; character &lt;ins&gt;µ , which has the universal character name &lt;/ins&gt; U+00B5 cannot be represented in the &lt;ins&gt;execution&lt;/ins&gt; encoding &lt;del&gt;used for&lt;/del&gt;&lt;ins&gt; associated with the character type &lt;/ins&gt; charT, the unit suffix "us" is used instead of "µs".</pre>
                                  </blockquote>
                                </blockquote>
                                <br>
                                <div>Howard and I discussed the wording
                                  I proposed today and we're now on the
                                  same page with regard to the intent.<br>
                                </div>
                                <div><br>
                                </div>
                                <div>With regard to Corentin's suggested
                                  wording above, "abstract character"
                                  and "execution encoding" are not
                                  current terms in the standard (well,
                                  the former is inherited from our
                                  reference to the Unicode standard but
                                  is otherwise unused at present). 
                                  <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1859r0&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033899949&amp;sdata=oRDqgPM%2BQYpE7tvZ%2FNdfTgdtQfJ4IlCfccsiCFj3aWU%3D&amp;reserved=0"
originalsrc="http://wg21.link/p1859r0"
shash="E/nTKArAw9NXVuoKaBTELqePmC4Le4cVRP9obysiYCnJ1jtuUeewlVxdPy2TS3W/RnoXUqTD6fZdIF3zaN17po3IaCutRiyBViNJNW1hOl/oE/wPSvbkCNbMc3dWrqsO04UupjqUon9xKmtjYZx2+4wjgM82Sk3LxvwdUuPthsI="
                                    target="_blank"
                                    moz-do-not-send="true">
                                    P1859R0</a> does intend to
                                  standardize new terminology, but we
                                  don't yet have consensus for what the
                                  new terms should be named.  I think we
                                  should avoid using candidate names
                                  until we have such consensus.<br>
                                </div>
                                <div><br>
                                </div>
                                <div>Tom.<br>
                                </div>
                                <div><br>
                                </div>
                                <blockquote type="cite">
                                  <blockquote type="cite">
                                    <blockquote type="cite">
                                      <pre>On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
A new LWG issue was filed for this question today:
- <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033899949&amp;sdata=U5A%2BsZ8XsYQl6KIQpM%2FdifLb70Hs3igIHBHVdsMPFyI%3D&amp;reserved=0" originalsrc="https://cplusplus.github.io/LWG/issue3314" shash="tRC/LzMNuCDeAfbDQ9tTDl2ZEFEa4QPnutAMOYe6x653kpQn9sj4OLPo3dRfoFW3xwcOe+8ov2H1n+nq4LAiLJpXxAthjyLYN5qoIPzkehbCbwkeHUvrcWHQpRE6CZl71uY+1eLLxCzuDMMiOqjWXOppLqDlLWpP4547sUe9aas=" target="_blank" moz-do-not-send="true">https://cplusplus.github.io/LWG/issue3314</a>

This issue concerns the ostream inserters added for std::chrono::duration in C++20 and what the intended behavior is for a duration when period::type is micro.

[<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftime.duration.io&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033909944&amp;sdata=GX4dXIwJ%2FLbhh%2BIOPS8nm0WqPZDRGbW38BEd450UsFw%3D&amp;reserved=0" originalsrc="http://time.duration.io" shash="hvasKRvORmRV3313CPDLFeU53o+HzHMp59sKdTUpA92iIgOfFelK09WujYiiLXFnYiOirk0kXRKQZwTOTIrs/cdGcNkJKT3oHC0rxJzWOGOHtzF/F8gBZYP8I5pyb5YY7DYGyxLHvF8QvdK77RbbPjr13R4Ik62wHZk839nOQuM=" target="_blank" moz-do-not-send="true">time.duration.io</a>]p4 states:


</pre>
                                      <blockquote type="cite">
                                        <pre>If Period​::​type is micro, but the character U+00B5 cannot be represented in the encoding used for charT,           the unit suffix "us" is used instead of "μs".

</pre>
                                      </blockquote>
                                      <pre>The question is with regard to which one of the encodings used for charT is referred to here; the compile-time execution character set or the run-time locale dependent native character set?

The proposed resolution specifies that the compile-time execution character set is the intended one.  My expectation is that this aligns with existing implementations, but I haven't checked.

Tom.

</pre>
                                    </blockquote>
                                    <pre>_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033909944&amp;sdata=ChXa5r4gFfKFLSCp5W0r5KxJp2wQXITkyc%2Fl4qj7T%2FU%3D&amp;reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="sKuOf9mFOnFzyPI7JHinDf9Fx4ITlFLFUfkQV1BJTrDohc/pfpfj5QzN1mdFAjhRHRiFhOJ9tkUuL8ewdhvEHDRqyUBKRzHefYxp6cW8xG/tj94PqS4qunfEA55O/TukvvGbbS96k+UuOv1TQKqnMuK00B11N7lGYdDTxxTNA4c=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13309.php&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033919938&amp;sdata=LvQSK0LbtvfCPYA%2BJEUGBQcc4xgqYrqIVOW%2BfzKZFNA%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13309.php" shash="J7qpSSvrmGmc6Sybav8hhyWuq4wtmfzTydwWlmWlXmnAwRJwntMz+6eOyG/wVhrNtPTCLT6OWg9MCIRGoL0gngc55ftSE/hEptSyOIPgnZoI3cxs8/5BbAuD3MavcU1CHKWE/49OiU5vT8KETzn9wetYK7zNsDKC4TK+/r3fPD4=" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/lib-ext/2019/11/13309.php</a>
_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033919938&amp;sdata=HwWb%2F5ULhnKvs1vwyWfcE4fOrit5SFLKBLIyJp13VHA%3D&amp;reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="S9//+zc2ZKrOpTd1RxBg2W91Uqa6B4LcISlx7rMAwRgU0zDLvF5hrYNrw6LeuzitJPEQFs2k1cfFaQDjibPsL4eUau+HfER1VWpFsGopWNPWb+LN2a+WjZcj/i0O+8KQodviEmvnVBJ6+W7Wp6fmhKajW59KFzI0lFSDDYE0NC4=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13325.php&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033929933&amp;sdata=zNBIMvgu6Y7ljSTA37qaM%2Fs6n7hs4CKqXLplDGiQ0TY%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13325.php" shash="P16+0wt58HAAGI6ywmxrW8Lq/n+6GPbQ9q/CKpE82XVDVI3L7M/n4jUwAZjgvsXD8YfSTShyL/i+ZC3ThHkD4rlRLI78kTvybyUey9PGmKNsDeGJ9/8+PQ4xuSZsBRjNbUpJ15ZdaZRbXdzBjP1ba0E+WHCj4AM3BvLhZn7xtEE=" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/lib-ext/2019/11/13325.php</a>
</pre>
                                  </blockquote>
                                  <br>
                                  <fieldset></fieldset>
                                  <pre>_______________________________________________
SG16 Unicode mailing list
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank" moz-do-not-send="true">Unicode@isocpp.open-std.org</a>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Funicode&amp;data=02%7C01%7Cbion%40microsoft.com%7C371c6ae112934c8e66ca08d7630cd250%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086779033929933&amp;sdata=ggFj6DMw%2FETMywUoNGjMBw1Fp5ZsWRJHDmCf05Kohtg%3D&amp;reserved=0" originalsrc="http://www.open-std.org/mailman/listinfo/unicode" shash="xlckveWFmc+DhPBeiplSjzvJUdbIkPOlI+MCsYvHsaBh/CgyLiVyeHoHRFXSy1fq2/gA6sds1LhFXji7EV6+LhsIESDhpSvfJKVhySYgQdGcBJe97emIr99OVaQPz/gd0Bm7ANNc0DVyOx4TVCV2gm4hhaD6xoHbggLfK5rPN3Q=" target="_blank" moz-do-not-send="true">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
                                </blockquote>
                                <p><br>
                                </p>
                              </div>
                            </blockquote>
                          </div>
                        </div>
                      </blockquote>
                    </div>
                  </div>
                </blockquote>
                <p><br>
                </p>
              </div>
            </blockquote>
            <p><br>
            </p>
          </div>
        </blockquote>
        <p><br>
        </p>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>