Don't really see why you need manipulators. If you want to use the US date format do setlocale("US"), if you want German dates do setlocale("DE") etc. That is how you do it if you want numbers formatted and don't see why dates are any different.
I don't want to use the "US", "German" or any other specific regional settings - I want to use *my* settings.
If you are writing an application that need to parse/print dates in a more generic matter use a facet just as you do to handle different decimal separators.
But this is just most inconvenient...
I think of specifying the format string as similar to specifying the printing precision of a float, or specifying that an integer should be printed as hex. These are provided as manipulators without the complexity of facets (which most users, including me, know very little about).
I don't agree with that comparison. Date formatting is more like the number formatting (decimal separator, grouping etc) which is part of the locale for numbers.
You have a point with the decimal separator issue (decimal separator as an example). After thinking about it some more, perhaps what I'm complaining about is something that is general in the locale/facet system. Maybe what's really bothering me is that once a certain setting is considered as "locale related", such as the decimal separator, it can only be configured using the locale/facet over-complicated way. But sometimes I don't want to use the "US", "German" or any other local setting for a decimal separator - I want to use *my* decimal separator. I souldn'd be forced to use a locale in such cases, IMO. IOW, I wish *all* settings would be configurable using manipulators (or an equivalent convenient way), and yes, that includes a decimal separator manipulator... The date_time I/O just brought all this to the surface, because setting a date/time format string is much more common than setting a decimal separator, but in principal it's the same thing...