Huh ... I wonder if this really counts as editorial after so long. The standard has been "wrong" for so long, maybe people have been implementing do_get_date overriders according to the spec, and would be broken by "fixing" the standard.

You're saying stuff that exists gets used and people expect it to always be the way it is? Wild. Surely people will consult their ISO documents in their local library.

@cpplearner Thanks a lot for digging that up, but I think I agree with @jwakely that we should probably make this an LWG issue. That said, it's a good time to file issues, since issue processing is now a high priority.

FWIW libstdc++ doesn't implement the resolution of DR 461 (we just parse the locale's %x format, which means we have exactly the problem described in the DR). So we would be unaffected by inserting the missing slashes.

FWIW libstdc++ doesn't implement the resolution of DR 461 (we just parse the locale's %x format, which means we have exactly the problem described in the DR). So we would be unaffected by inserting the missing slashes.

Neither do libc++ and MSVC's STL. libc++ also analyzes the locale's %x format. MSVC's do_get_date tries more orders in addition to the one represented by date_order, and accepts :, , and / as separators.

It seems that libc++ only examines the %x format for time_get_byname, not for time_get.

We should just deprecate this nonsense anyway:

• 2-digit dates are bad
• there's no way for time_get::do_date_order() to find out the locale's preferred format because it doesn't have an ios_base& argument from which to get the locale
• many locales don't use one of those four formats, e.g. de_DE uses %d.%m.%Y and fr_FR uses %d/%m/%Y

The whole DR 461 resolution seems to be a way to get some kind of bad approximation of D_FMT for implementations that can't access the locale's D_FMT. But if the implementation can access that, then do_date_order() is worse than useless.

LWG 461 does permit implementations to support D_FMT, in addition to the formats listed in [tab:locale.time.get.dogetdate].

[locale.time.get.virtuals]/5:

An implementation may also accept additional implementation-defined formats.

I'm not sure how it's possible to also support other formats. If D_FMT and do_date_order disagree, the implementation needs to pick one. It can't support both if the formats are ambiguous, like %d/%m/%y and %m/%d/%y, and the input is "01/02/03". A correct implementation should support other formats instead of the one indicated by do_date_order().

Filed LWG 4285