1. Why doesn't date_time use the standard time facet (time_put.do_put etc) if the special greg_date_facet isn't available?
Couple reasons. We have looked at using the current facets, and sadly, in our testing we found most of the current facet implementations don't work correctly
That is what I suspected. Thanks for the explanation.
-- so even if we did use them it wouldn't work. Second, the standard facet doesn't cover all values that date_time offers such as infinities, not-a-date-time, etc.
I was only suggesting to use the standard facet as a fallback solution since that way you don't have to mess with local formatting in user messages. Currently I convert the date/time to "struct tm" and use strftime.
Yes we realize this is a pain. The plan is to provide manipulators to control these aspects so you don't have to mess with the facet to control seperators and ordering.
Maybe it is just me but I prefer the facet way since then I can apply it either globally or to a specific stream. With manipulators there is no way to control the date format used in e.g. the program options library. Why not create a facet which uses the standard strftime formatters and also lets you use custom names for days & months. If %a,%b etc is specified just check if custom names are available, otherwise let the standard time_put::put () (or strftime) handle it. %c,%x & %X should always be handled by time_put. With this facet you can do: xmlstream.imbue(locale(locale::classic(), new date_time_facet("%Y-%m-%dT%H:%M:% S"))); Parsing date input is always tricky but isn't that a reason to have it as a library function. Different facets or constructor overloads is probably needed to handle different cases like only date, only time & intervals. I can help with implementation if you like.