This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4285. time_get::do_get_date is problematic even after LWG 461

Section: 28.3.4.6.2.2 [locale.time.get.members] Status: New Submitter: S. B. Tam Opened: 2025-06-27 Last modified: 2025-06-28

Priority: Not Prioritized

View all issues with New status.

Discussion:

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

LWG 461(i) 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(i) 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 28.3.4.6.2.3 [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().

Proposed resolution: