GNOME Bugzilla – Bug 83145
g_date_strftime optimization
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] g_date_strftime optimization
This looks wrong; UTF-8 is a multi-byte encoding, not a wide character encoding. So 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 two. 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.