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 <ins>abstract</ins> character <ins>µ ,
which has the universal character name </ins> U+00B5 cannot be represented
in the <ins>execution</ins> encoding <del>used for</del><ins> associated
with the character type </ins> charT, the unit suffix "us" is used instead
of "µs".


On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <
lib-ext_at_[hidden]> wrote:

> A new LWG issue was filed for this question today:
> - https://cplusplus.github.io/LWG/issue3314
>
> 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.
>
> [time.duration.io]p4 <http://eel.is/c++draft/time.duration.io#4> states:
>
> 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".
>
> 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.
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php
>