Re: date zh_TW.Big5 +%P

[Abel Cheung]

On 3/23/05, Abel Cheung <address@hidden> wrote:

So if coreutils maintainers think this is not a bug, or "this is your own
business", then please tell me so that I can ask localization teams
to think about other way to work around it.

Abel


> About the bug, it is definitely not related to translation. date is taking
> glibc definition for %p and %P format, not from po file at all. However,
> there is no problem in glibc definition as well. I have about 70%
> confidence this problem comes from the evil tolower() call in
> lib/strftime.c, which failed to handle some particular multibyte charsets --
> those including ASCII in byte range. Big5 is such a charset.
> 
> The problematic character reporter talk about is:
> %p: \xa4\x57
> %P: \xa4\x77
> 
> And tolower("\x57") = \x77. But even if this is true,
> I'm not sure how can it be solved; probably converting string into
> some charset known not to contain ASCII for multibyte char (such as
> UTF-8) before tolower()? I guess this can be a workaround, but not
> such about the cost of such hack.