> 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'.
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?