GNOME Bugzilla – Bug 83145
Last modified: 2011-02-18 16:13:45 UTC
Current implementation always converts to locale encoding and uses strftime.
On newer systems there is wcsftime, which works on UTF-8 strings, so no
conversion is needed. The attached patch makes use wcsftime if it is available.
Created attachment 8753 [details] [review]
This looks wrong; UTF-8 is a multi-byte encoding, not a wide character
either we have to use a "mb" function, or stick an
mbtowcs in there.
Oh, it is wrong :( Just tested myself.
But converting to and from locale charset is also wrong.
When I do
mbstowcs(formatw, format, sizeof(formatw));
wcsftime(bufferw, sizeof(bufferw), formatw, tm);
wcstombs(buffer, bufferw, sizeof(buffer));
I get back a string in locale encoding, not UTF-8 as I expected.
How could I implement this without converting to locale encoding, and
still operate only on UTF-8 strings?
Having such problems I certainly want g_utf8_strftime (bug 69140),
because switching to locale encoding just to format time every second
is nonsense. Just look into panel clock :(
Note that g_date_strftime() does not currently switch
encodings; it just converts the format string to the
encoding of the locale and back.
There actually used to be an optiimzation in g_date_strftime()
if the encoding of the locale was UTF-8, but we decided
that the buffer handling in strftime() was so badly
messed up that it was better to have one codepath than
See gunicollate.c:g_utf8_collate() for an example
of using wcs functions to implement UTF-8 functions correctly;
however I think for g_date_strftime() the "buffer handling
is too hard to duplicate twice" argument probably
applies for this as well.
For a g_format_time() or somethign with reasonable buffer
semantics, doing optimizaitons would make more sense.
Does this bug need to stay open?
So the patch is wrong, g_date_strftime works as it is, closing the bug.