Domanda

The implementation of wcsftime that ships with the Visual Studio CRT seems to have a completely unbelievable bug! It just doesn't support unicode, as far as I can tell.

Internally, it translates to single-byte (using the current single-byte codepage), then calls strftime, then goes back to multibyte. What a joke! Why do they ship a wide version if it's no better than the narrow one?

If I call wcsftime(L"ümlaut ş"), the umlaut works (because it's contained in Latin-1) but the s-cedilla won't (it comes out as L"ümlaut ?").

All I want is to write a wrapper around wcsftime that returns UTF-8 data, but I can't seem to get the full range of Unicode out of wcsftime (let alone strftime), no matter what I do.

Are these functions just fundamentally broken in the CRT? Do I have to ship my own implementation just to get strftime format strings working in my cross-platform application?

È stato utile?

Soluzione

It is a known problem with wcsftime, you simply should not format date and time with characters in format that are not from selected locale. You can also try using GetDateFormat / GetTimeFormat functions, but I am not sure if they will work as you want. Other solution is to encode all characters to hex (for example "ş" <-> "@015E") before calling wcsftime and decode after calling it.

Altri suggerimenti

For the record, my solution was to implement my own strftime (adding it to the list of fourteen groups of ISO C functions I already have to re-implement on Windows). My strftime uses locale correctly, takes a UTF-8 format string, and replaces the tokens appropriately with data obtained directly from GetLocaleInfoEx and GetDateFormatW, unlike the broken CRT version. Sigh.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top