chrono
types is underspecifiedSection: 30.12 [time.format] Status: Resolved Submitter: Victor Zverovich Opened: 2021-05-31 Last modified: 2023-03-23
Priority: 2
View other active issues in [time.format].
View all other issues in [time.format].
View all issues with Resolved status.
Discussion:
When formatting chrono types using a locale the result is underspecified, possibly a mix of the literal and locale encodings. For example:
std::locale::global(std::locale("Russian.1251")); auto s = std::format("День недели: {}", std::chrono::Monday);
(Note that "{}
" should be replaced with "{:L}
" if P2372 is adopted but that's non-essential.)
"Russian.1251"
locale exists we have a mismatch between encodings.
As far as I can see the standard doesn't specify what happens in this case.
One possible and undesirable result is
"День недели: \xcf\xed"
where "\xcf\xed"
is "Пн"
(Mon in Russian) in CP1251 and is not valid UTF-8.
"День недели: Пн"
where everything is in one encoding (UTF-8).
This issue is not resolved by LWG 3547 / P2372 but the resolution proposed here is compatible with P2372 and can be rebased onto its wording if the paper is adopted.[2021-06-14; Reflector poll]
Set priority to 2 after reflector poll. Send to SG16.
Previous resolution [SUPERSEDED]:
This wording is relative to N4885.
Modify 30.12 [time.format] as indicated:
-2- Each conversion specifier conversion-spec is replaced by appropriate characters as described in Table [tab:time.format.spec]; the formats specified in ISO 8601:2004 shall be used where so described. Some of the conversion specifiers depend on the locale that is passed to the formatting function if the latter takes one, or the global locale otherwise. If the string literal encoding is UTF-8 the replacement of a conversion specifier that depends on the locale is transcoded to UTF-8 for narrow strings, otherwise the replacement is taken as is. If the formatted object does not contain the information the conversion specifier refers to, an exception of type
format_error
is thrown.
[2023-03-22 Resolved by the adoption of P2419R2 in the July 2022 virtual plenary. Status changed: SG16 → Resolved.]
Proposed resolution: