On Sun, Nov 3, 2019, 10:47 Howard Hinnant <howard.hinnant_at_[hidden]> wrote:

> The intent is to use Unicode to get “μs” without involving a locale. That
> would be UTF-8 for char, UTF-16 for a 2 byte wchar_t and UTF-32 for a 4
> byte wchar_t. And if for some reason the device can’t deal with Unicode,
> the vendor can fall back to “us” in the basic character set. In either
> event, it is not intended to involve a locale, and specifically doesn’t not
> involve the ctype facet and widening/narrowing. I’m not sure I would call
> it implementation defined as the vendor isn’t required to document it. But
> the vendor can choose between the Unicode output, or the “us” approximation.
>
> Feel free to submit an issue, but if you do I strongly recommend suggested
> wording as the LWG has already been over this paragraph in detail and the
> current wording is a product of that review.
>

It seems fine given that we need to untangle locale and encodings anyway -
this can already be implemented without locale even if the standard doesn't
specify how.

>
> Howard
>
> On Nov 3, 2019, at 8:16 AM, Tom Honermann <tom_at_[hidden]> wrote:
> >
> > I just came across [time.duration.io]p4:
> >
> > > 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".
> >
> > How is the determination as to whether the character can be represented
> to be done? It seems this would involve consulting the locale. Or is this
> effectively implementation defined behavior?
> >
> > Perhaps this is worth an LWG issue to at least clarify the behavior?
> >
> > Tom.
> >
>
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>