https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2003-12-01 00:55:30 |2025-6-24
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Unfortunately, at the time I overlooked this comment in locale_facets.tcc:
>
> // NB: Not especially useful. Without an ios_base object or some
> // kind of locale reference, we are left clawing at the air where
> // the side of the mountain used to be...
> template<typename _CharT, typename _InIter>
> time_base::dateorder
> time_get<_CharT, _InIter>::do_date_order() const
> { return time_base::no_order; }
>
> Having written the parsing code, now I have no idea how to circumvent the
> above issue, for the moment I'm unassigning myself from the PR.
Yeah, nice ... we can't access the __timepunct facet without a reference to the
std::locale, so we can't get the D_FMT string.
A derived std::time_get can return something different from its
do_date_order(), if it wants to.
We could also have a custom facet derived from time_get that we store in the
std::locale when it is created by name from a C locale, and store a dateorder
enum in that derived type on construction. That would allow std::time_get
facets that are associated with a C locale to return a correct dateorder for
the locale (but only if the locale's D_FMT happens to map to one of the four
distinct dateorder formats!)
Of course this seems pretty useless since our std::time_get::do_get_date
ignores the dateorder anyway, and just uses D_FMT directly, which is much more
useful (and supports alternative formats like the is_IS one).
What we could do is change the default do_date_order() to return mdy instead of
no_order, which would be correct for the C locale and _some_ locales such as
en_US (see Bug 99556), but completely wrong for most other locales. I'm not
sure that's an improvement.
