| From: | Surafel Temesgen <surafel3000(at)gmail(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Vik Fearing <vik(dot)fearing(at)enterprisedb(dot)com> |
| Subject: | Re: Calendar support in localization |
| Date: | 2021-03-31 14:38:27 |
| Message-ID: | CALAY4q_ZYwiO1BfjLfzpC6dSxFT1RFcj4kq+7FYjfdOT1GpS_A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 30, 2021 at 11:16 AM Daniel Verite <daniel(at)manitou-mail(dot)org>
wrote:
>
> The conversions from julian dates are not necessarily hard, but the
> I/O functions means having localized names for all days, months, eras
> of all calendars in all supported languages. If you're thinking of
> implementing this from scratch (without the ICU dependency), where
> would these names come from? OTOH if we're using ICU, then why
> bother reinventing the julian-to-calendars conversions that ICU
> already does?
>
>
i donno why but currently we are using our own function for
converting (see j2date and date2j) maybe it's written before ICU but i
think ICU helps in adding other calendar support easly. Regarding I/O
functions postgresql hard coded days and months names on array and just
parse and string compare, if it is not on the list then error(see
datetime.c) and it will be the same for other calendar but i think we don't
need all that if we use ICU
regards
Surafel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2021-03-31 14:44:19 | Re: Prevent query cancel packets from being replayed by an attacker (From TODO) |
| Previous Message | Alvaro Herrera | 2021-03-31 14:18:45 | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |