Title
`time_get::do_get_date` is problematic even after LWG 461
Status
new
Section
[locale.time.get.members]
Submitter
S. B. Tam

Created on 2025-06-27.00:00:00 last changed 5 days ago

Messages

Date: 2025-06-27.00:00:00

Background: https://github.com/cplusplus/draft/pull/8009

LWG 461 changed `time_get::do_get_date` to parse a set of fixed formats. For example, if `time_get::date_order()` is `no_order` or `mdy`, the format parsed by `do_get_date` is `%m/%d/%y`.

This has several problems:

  1. When the resolution of LWG 461 was applied to the draft standard, the slashes were lost. This could mislead people into implementing `do_get_date` using the incorrect formats. Fortunately, none of the standard library implementations are affected by this mistake.

  2. Only 2-digit years are accepted due to the use of `%y`. This could lead to incorrect parse if `strftime` uses `%Y` for the locale's date format.

  3. `date_order()` might need additional locale facets to find out the date order, but it doesn't have an ios_base& argument from which to get the locale.

  4. Many locales do not use any of the specified formats. For example, `de_DE` uses `%d.%m.%Y`, `zh_CN` uses `%Y年%m月%d日`. Although [locale.time.get.virtuals]/5 gives an implementation the latitude to accept additional formats, ambiguity could arise if the locale's format disagrees with `date_order()`.

On POSIX systems, it is possible to query the locale's date format using `nl_langinfo(D_FMT)`. Maybe an implementation should be allowed to use that format instead of the one indicated by `date_order()`.

History
Date User Action Args
2025-06-27 00:00:00admincreate