If the encoding is intended as the one used for literals of type charT,
then locale does not have to be involved. That does run the risk of "?s"
being produced instead of "μs" .
If the encoding is latin-7, is it supposed to produce "μs"?

On Sun, Nov 3, 2019, 09: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.
>
> 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
>