How do you explain that the workaround works, then? When I don't send any ptime to wcout, all wcin / wcout i/o works as expected, including international characters (all I do is call setlocale(LC_ALL, ".OEM"); at startup).
I'm not sure which workaround you're referring to I'm afraid. I didn't notice any call to setlocale in your example. As for why the \x161 displays I don't know (if that is what you are saying happens). Is it a character available in the code page for the machine you are using?
The workaround is that I format ptime via wostringstream rather than directly send it to wcout. The character \x161 displays correctly in the first case, but does not (or, more exactly - looks differently) after sending a ptime to wcout.
The Unicode for the console should be able to handle the full range of display restricted only by the font in use. The streams implementation doesn't have such wide applicability though as it narrows it to eight bit output. All the experimentation I've done leads me to the conclusion that _cputws is able to display the widest range of characters properly, but only if you start the command shell with the Unicode handling turned on.
That does not matter much, I think. The "setlocale(LC_ALL, ".OEM")" call was indeed left out from my example, as it only ensures that characters received via wcin are correctly translated to wchar_t (I assume that the other option is running cmd /u, thanks for the tip!). If I don't call this, the characters that I read from the console via wcin are different from what I see in the debugger watch window, however they are translated to their original form when printed back to wcout. (Unless I send a ptime to wcout, that is.)
I'm not suggesting that this is the only possible explanation for what you are seeing, but it seemed a reasonable possibility given your description.
:-) I'm *not* having problems reading/writing international characters as long as I don't send ptime to wcout. I did some debugging on the matter and I suspect that the line boost/date_time/posix_time/posix_time_io.hpp:61 is the culprit. It changes the locale of wcout and whatever machinery should revert this back, it does not. This agrees with my observation that using a wostringstream for formatting does not damage wcout. What do you think? Cheers, Filip