Comment 17 for bug 128496

Now I also added tests to my branch, and got problems in japan and russia, the only non-latin locales available on my system.
It seems that osutils.format_date doesn't return a unicode string, but rather a byte sequence.
Fixed one instance in log.LongLogFormatter.log_revision but there might be others affected as well.
osutils.format_date(...).decode() didn't work as I would have expected.
osutils.format_date(...).decode("utf-8") did work, but I'm not sure how it would do in a non-latin1 non-utf8 locale, like some of the pre-unicode asian locales. Someone care to check?

Some possible solutions:
1. Make osutils.format_date use POSIX locale. This is current behaviour in bzr.dev but I suppose it's bad for users who don't instantly understanding english weekday names. Would reduce the worth of the whole setlocale attempt.
2. Check every occurrence of osutils.format_date and figure out whether the caller needs a unicode string, UTF-8 string or a string in current default or terminal encoding. Probably it would be best if there was a test case for each of these invocations, so one would have to figure out command line commands that use them.

I'll need some developer opinion on this before I put any more work into something that might already be doomed.