| 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 |