From: | Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: to_char and i18n |
Date: | 2005-12-22 04:10:43 |
Message-ID: | m33bklsrek.fsf@conexa.fciencias.unam.mx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> Can you give a small introduction of i18n and what's your plan in
> PostgreSQL?
i18n == Internationalization (maybe I should say l10n ==
localization). This means that to_char functions might lead to
different results depending on the i18n settings. For instance,
nowadays, select to_char(now(), 'dd-mon-yy') returns 21-dec-05
regardless of the i18n settings. This should lead 21-dic-05 in the
es_MX localization. This also applies to the concurrency symbol,
thousand separator, etc.
(Some time ago I proposed an--incomplete--patch and it was rejectd by
Karel arguing that to_char functions should behave *exactly* the same
way that they do in Oracle.)
Regards,
Manuel.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-22 04:17:08 | Re: to_char and i18n |
Previous Message | Bruce Momjian | 2005-12-22 04:07:13 | Re: Does VACUUM reorder tables on clustered indices |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-22 04:17:08 | Re: to_char and i18n |
Previous Message | Qingqing Zhou | 2005-12-22 03:49:45 | Re: to_char and i18n |