(Check severity to normal - if you follow the link
for the Severity field, you'll find "Critical" is:
"crashes, loss of data, severe memory leak".)

Yes, this would be a good addition for 2.2. Implementation
is not at all easy - the implementation in 
g_date_strftime only works if all characters in the
format are representable in the encoding of the current
locale, which is not satisfactory.

An approach that can be taken on some systems:
if __STDC_ISO_10646__ is defined, use wcsftime and
then convert the result from UCS-4 => UTF-8.

The combination of those two approaches may have to suffice - 
reimplementing strftime from scratch with correct localization 
does not really seem feasible.

Hi Owen! What a fast response!
Yes, the category I chose was slightly overstated.
On your note - I think you are totally wrong (may be because I didn't specify the way it should be implemented).
I see implementation as
setlocale(LC_DATE,<current locale but with utf8 codeset>)
char* val = strftime(..);
setlocale(LC_DATE,<saved value of LC_DATE, that was before the call>)
return val;
This way the argument of g_strftime can be of any codeset (in fact it will be utf8 since it will be localized string returned by gettext() or ascii), and return value will be in utf8.
I don't see any problems with this apporach - do you?
I think it's very important to provide this wrapper for glib 2.0 - otherwise we will get hundreds of lame programs that will use strftime instead of g_strftime and thus will work
incorrectly under non-ascii locales.

- GLib is supposed to be thread safe. setlocale() is global
  for all threads, so the setlocale/setlocale-back hack
  can cause problems.

- How do you find out a locale like the current locale but
  with a UTF-8 charset? What if there isn't one? 
  (The system may not have UTF-8 locale support, or the
  user may not have installed a UTF-8 locale corresponding
  to the current locale.)

Hopefully, most people who need to call strftime will do:

   strftime ("[ascii format]", ...)
   result = g_locale_to_utf8 (buffer);

  If they don't do that, the results will be wrong not just
  for Russian and Japanese, but also for German, and French,
  so they'll get a patch quickly.

  I don't think you actually need a format string with localized  
  content at all commonly.

(And note that the buffer handling for strftime is _horrible_ -
a g_format_time should definitely return an alloced buffer
of the right length 

As for thread safety - I think any mature software package has mutexes for accessing
locale-dependant functions, so nothing will go wrong for properly
written software (just remember that for some locales fraction separator
is different from "." and you'll see that any s/w with portable text IO will
require mutexes).
As for unavilability of matching utf8 locale - yes, you are right.
Unfortunately statistics shows that there is a lot of lame code that
is completely broken for multibyte encodins and works with major
problems with non-latin1 encodins. So I wouldn't be (since I'm not)
that optimistical about availability of fixed software..
Why not just do write g_strftime
like you proposed (call strftime, convert result to utf8)? And agressively advertize g_strftime?
This will allow to fix horrors of buffer handling in strftime too :)

I just thought again,
Now it seems to me that format strings with non-ascii chars are not that uncommon,
size of data to support additional locale is not that big (no more than
200K), so it would be better to shout loudly that corresponding locale
is not installed, while trying to to utilize corresponding
locale with utf8 charset.
In the worst case, handcrafted format fields merging could be implemented
to allow to use format strings with non-ascii characters in it.
Anyway, some sort of proxy (wrapper) is required IMO.

Is this a duplicate of #69140 ?

*** This bug has been marked as a duplicate of 69140 ***