Re: Calendar support in localization - Mailing list pgsql-hackers

From Surafel Temesgen
Subject Re: Calendar support in localization
Date
Msg-id CALAY4q8ubcapJrYMyP-NzOiHwPW_hZJLOiwznk5npchEAnrh3g@mail.gmail.com
Whole thread Raw
In response to Re: Calendar support in localization  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers


On Wed, Mar 17, 2021 at 3:39 PM Thomas Munro <thomas.munro@gmail.com> wrote:
On Thu, Mar 18, 2021 at 3:48 AM Tom Lane <tgl@sss.pgh.pa.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@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

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Bruce Momjian
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?