Thread: Solve a problem of LC_TIME of windows.
Hi. I have problem of LC_TIME of windows.(CVS-HEAD) As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is expressed.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png As for Version 8.4. It came to be used by Tom-san in strftime of Native-windowsAPI. It is good improvement.! But, strftime of Native returns a result by CODEPAGE of environment of operation by Windows with LC_TIME. In Japanese environment, return value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by SERVER_ENCODING.:-( http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png Then, I'm proposal patch. It is solved splendidly. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt Regards, Hiroshi Saito
Attachment
Hiroshi Saito wrote: > Hi. > > I have problem of LC_TIME of windows.(CVS-HEAD) > > As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is > expressed.) > http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png > > > As for Version 8.4. It came to be used by Tom-san in strftime of > Native-windowsAPI. > It is good improvement.! But, strftime of Native returns a result by > CODEPAGE of > environment of operation by Windows with LC_TIME. In Japanese > environment, return > value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by > SERVER_ENCODING.:-( > http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png > > Then, I'm proposal patch. It is solved splendidly. > http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt > > http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt In principle, I think this patch looks good. Do you (or somebody else) have an example where this breaks in an encoding where I can actually understand the characters, though ;-) That would make testing a whole lot easier... Also, the patch needs error checking. strftime() can fail, and the multibyte conversion functions can certainly fail. That will need to be added. //Magnus
Magnus Hagander wrote: > Also, the patch needs error checking. strftime() can fail, and the > multibyte conversion functions can certainly fail. That will need to be > added. What about this line? #define STRLEN_MAX 255 Are we really sure the strftime format cannot be longer than that? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Hi. ----- Original Message ----- From: "Magnus Hagander" <magnus@hagander.net> > In principle, I think this patch looks good. > > Do you (or somebody else) have an example where this breaks in an > encoding where I can actually understand the characters, though ;-) That > would make testing a whole lot easier... > > Also, the patch needs error checking. strftime() can fail, and the > multibyte conversion functions can certainly fail. That will need to be > added. Ok, thanks! strftime return to 0. http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx MultiByteToWideChar and WideCharToMultiByte return to GetLastError. http://msdn.microsoft.com/en-us/library/ms776413(VS.85).aspx I will proposal the next patch.:-) BTW, this is SQL for a check. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK.sql Probably, all are included. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/LC_TIME_CHECK_LOCALE.sql Regards, Hiroshi Saito
Hi.
----- Original Message -----
From: "Alvaro Herrera" <alvherre@commandprompt.com>
> What about this line?
>
> #define STRLEN_MAX 255
>
> Are we really sure the strftime format cannot be longer than that?
Ahh, although the place to replace is here, is it said that MAX_L10 N_DATA is suitable?
--
cache_locale_time(void)
{
..
char buf[MAX_L10N_DATA];
..
strftime(buf, MAX_L10N_DATA, "%a", timeinfo);
Regards,
Hiroshi Saito