Subject: Re: [SG16-Unicode] [isocpp-lib-ext] [time.duration.io] : Is stream insertion behavior locale dependent when Period::type is micro?
From: Corentin (corentin.jabot_at_[hidden])
Date: 2019-11-05 16:32:27
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
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
On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <
> 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.
> Lib-Ext mailing list
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php
SG16 list run by herb.sutter at gmail.com