Solve a problem of LC_TIME of windows.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Solve a problem of LC_TIME of windows.

Hiroshi Saito-2
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


--
Sent via pgsql-patches mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

pg_locale_patch-v3 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Solve a problem of LC_TIME of windows.

Magnus Hagander-2
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

--
Sent via pgsql-patches mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Reply | Threaded
Open this post in threaded view
|

Re: Solve a problem of LC_TIME of windows.

Alvaro Herrera-7
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.

--
Sent via pgsql-patches mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Reply | Threaded
Open this post in threaded view
|

Re: Solve a problem of LC_TIME of windows.

Hiroshi Saito-2
In reply to this post by Magnus Hagander-2
Hi.

----- Original Message -----
From: "Magnus Hagander" <[hidden email]>

> 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

--
Sent via pgsql-patches mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Reply | Threaded
Open this post in threaded view
|

Re: Solve a problem of LC_TIME of windows.

Hiroshi Saito-2
In reply to this post by Alvaro Herrera-7
Hi.

----- Original Message -----
From: "Alvaro Herrera" <[hidden email]>
> 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

--
Sent via pgsql-patches mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches