Am Sonntag, 7. Oktober 2007 schrieb Gregory Stark:
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding
regardless,
It seems to me we aren't actually using strftime any
Am Samstag, 6. Oktober 2007 schrieb Tom Lane:
It's not real clear to me whether, on a Unix machine, there is even
supposed to be any difference between setting LC_TIME=es_ES.iso88591 and
setting it to es_ES.utf8. Since nl_langinfo(CODESET) is supposedly
determined only by LC_CTYPE, you could
Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an encoding different from
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
Gregory Stark [EMAIL PROTECTED] writes:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like
Gregory Stark [EMAIL PROTECTED] writes:
So does the _() macro automatically recode it to the current server encoding?
From the gettext manual:
---
gettext not only looks up a translation in a message catalog. It also
converts the translation on the fly to the desired output character
set. This
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
So does the _() macro automatically recode it to the current server encoding?
Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
If I have a different client_encoding and get a NOTICE, then both the
server
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
So does the _() macro automatically recode it to the current server
encoding?
Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
If I have a different client_encoding and get
Alvaro Herrera wrote:
Actually I was thinking about things like formatting.c which take localized
strings and return them as data which can end up in the database. If they're
in the wrong encoding then they'll be invalidly encoded strings in the
database.
Oh, I didn't think of that.
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Actually I was thinking about things like formatting.c which take
localized
strings and return them as data which can end up in the database. If
they're
in the wrong encoding then they'll be invalidly encoded strings in the
database.
Oh, I
Alvaro Herrera [EMAIL PROTECTED] writes:
I tried on both a UTF8 and Latin1 terminal and it works OK in all cases.
The cases that would be interesting involve to_char's locale-specific
format codes (eg Dy) along with LC_TIME settings that are deliberately
incompatible with the database encoding.
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding regardless,
It seems to me we aren't actually using strftime any more in any case. We seem
to be using things like
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding regardless,
It seems to me we aren't actually using strftime any more in any
Gregory Stark wrote:
It seems to me we aren't actually using strftime any more in any case. We seem
to be using things like _(Monday) instead. Except in my tests I don't get
any French dates even when the server is started in French mode. I think we
just don't have localizations for those
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an encoding different from the database's encoding?
16 matches
Mail list logo
