Re: Calendar support in localization

On Wed, Mar 17, 2021 at 3:39 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Thu, Mar 18, 2021 at 3:48 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Right, so if this is done by trying to extend Daniel Verite's icu_ext
> extension (link given earlier) and Robert's idea of a fast-castable
> type, I suppose you might want now()::icu_date + '1 month'::internal
> to advance you by one Ethiopic month if you have done SET
> icu_ext.ICU_LC_TIME = 'am_ET(at)calendar=traditional'. Or if using my
> first idea of just sticking with the core types, perhaps you'd have to
> replace stuff via search path... I admit that sounds rather error
> prone and fragile (I was thinking mainly of different functions, not
> operators). Either way, I suppose there'd also be more explicit
> functions for various operations including ones that take an extra
> argument if you want to use an explicit locale instead of relying on
> the ICU_LC_TIME setting. I dunno.
>
>
As you know internally timestamptz data type does't existe instead it
stored as integer kind and we depend on operating system and external
library for our date data type support so i think that put as on the
position for not be the first one to implement timestamptz data type thing
and i don't know who give as the casting for free?

regards
Surafel