ITAGAKI Takahiro wrote:
> Magnus Hagander <magnus@hagander.net> wrote:
>
>> ITAGAKI Takahiro wrote:
>>> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
>>> (at least encoding) on Windows.
>>>
>> Hmm. Is this actually cleaner than using the original method as
>> suggested? Because if I understand things right, that version did *not*
>> require the setting of LC_CTYPE? (this is the version that uses strftime
>> and does two conversions)
>
> No, we can't. I found strftime doesn't work if the database is
> initialized with non-C locale. It works only when lc_ctype = C and
> the encoding of lc_time is matched with Windows' one.
> On the other hand, wcsftime seems to be more robust.
> (The reason might come from mysterious msvcrt implementation.)
The setting of LC_CTYPE acts like a catalyst for wcsftime() to
work safely.
I checked the code around the patch and found the central function
cache_locale_time() is rarely called (at most once per LC_TIME change).
The function cache_locale_time() calls strftime() only 38(=7*2+12*2) times. Now I fundamentally agree with
Itagaki-san'spatch. Though
it may not be the most effective code, it looks like the clearest one.
regards,
Hiroshi Inoue