Re: Calendar support in localization

Hi Daniel,

On Fri, Mar 26, 2021 at 8:51 PM Daniel Verite <daniel(at)manitou-mail(dot)org>
wrote:

> Thomas Munro 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'.
>
> I've pushed a calendar branch on icu_ext [1] with preliminary support
> for non-gregorian calendars through ICU, so far with only format and parse
> of timetamptz.
>

Thanks

>
>
> I understand that adding months or years with some of the non-gregorian
> calendars should lead to different points in time than with the gregorian
> calendar.
>
> For instance with the ethiopic calendar, the query above displays today as
> 17/mägabit/2013 and 1 month from now as 18/miyazya/2013,
> while the correct result is probably 17/miyazya/2013 (?)
>
>
yes it should be 17/miyazya/2013 (?)

> I'm not sure at this point that there should be a new set of
> data/interval/timestamp types though, especially if considering
> the integration in core.
>
> About intervals, if there were locale-aware functions like
> add_interval(timestamptz, interval [, locale]) returns timestamptz
> or
> sub_timestamp(timestamptz, timestamptz [,locale]) returns interval
> that would use ICU to compute the results according to the locale,
> wouldn't it be good enough?
>
>
Yes it can be enough for now but there are patches proposed to support the
system and application time period which are in SQL standard and if we have
that feature the calendar has to be in core and It doesn't appear hard for
me to support the calendar locally. Postgresql itself does't store
Gregorian date it stores julian date(which is more accurate than gregorian
calendar) and almost all of function and operator is done using julian date
converted to second(TimestampTz) so what it takes to support calendar
locally is input/output function and a converter from and to julian
calendar and that may not be that much hard since most of the world
calendar is based on julian or gregorian calendar[0]. Thought?

0.https://en.wikipedia.org/wiki/List_of_calendars

regards
Surafel