Hi Surafel,
On Tue, Mar 16, 2021 at 3:48 AM Surafel Temesgen <surafel3...@gmail.com> wrote:
> My country(Ethiopia) is one of the nations that uses different kind of
> calendar than what PostgreSQL have so we are deprived from the benefit of
> data datatype. We just uses String to store date that limits our application
> quality greatly. The lag became even worst once application and system time
> support is available and it seems to me it is not fair to suggest to add
> other date data type kind and implementation for just different calendar that
> even not minor user group. Having calendar support to localization will be
> very very very very exciting feature for none Gregorian calendar user group
> and make so loved. As far as i can see the difficult thing is understanding
> different calendar. I can prepare a patch for Ethiopian calendar once we have
> consensus.
One key question here is whether you need a different date type or
just different operations (functions, operators etc) on the existing
types.
> I cc Thomas Munro and Vik because they have interest on this area
Last time it came up[1], I got as far as wondering if the best way
would be to write a set of ICU-based calendar functions. Would it be
enough for your needs to have Ethiopic calendar-aware date arithmetic
(add, subtract a month etc), date part extraction (get the current
Ethiopic day/month/year of a date), display and parsing, and have all
of these as functions that you have to call explicitly, but have them
take the standard built-in date and timestamp types, so that your
tables would store regular date and timestamp values? If not, what
else do you need?
ICU is very well maintained and widely used software, and PostgreSQL
already depends on it optionally, and that's enabled in all common
distributions. In other words, maybe all the logic you want exists
already in your process's memory, we just have to figure out how to
reach it from SQL. Another reason to use ICU is that we can solve
this problem once and then it'll work for many other calendars.
> Please don't suggests to fork from PostgreSQL just for this feature
I would start with an extension, and I'd try to do a small set of
simple functions, to let me write things like:
icu_format(now(), 'fr_FR@calendar=buddhist') to get a Buddhist
calendar with French words
icu_date_part('year', current_date, 'am_ET@calendar=traditional') to
get the current year in the Ethiopic calendar (2013 apparently)
Well, the first one probably also needs a format string too, actual
details to be worked out by reading the ICU manual...
Maybe instead of making a new extension, I might try to start from
https://github.com/dverite/icu_ext and see if it makes sense to extend
it to cover calendars.
Maybe one day ICU will become a hard dependency of PostgreSQL and
someone will propose all that stuff into core, and then maybe we could
start to think about the possibility of tighter integration with the
built-in date/time functions (and LC_TIME setting? seems complicated,
see also problems with setting LC_COLLATE/datcollate to an ICU
collation name, but I digress and that's a far off problem). I would
also study the SQL standard and maybe DB2 (highly subjective comment:
at a wild guess, the most likely commercial RDBMS to have done a good
job of this if anyone has) to see if they contemplate non-Gregorian
calendars, to get some feel for whether that would eventually be a
possibility to conform with whatever the standard says.
In summary, getting something of very high quality by using a widely
used open source library that we already use seems like a better plan
than trying to write and maintain our own specialist knowledge about
individual calendars. If there's something you need that can't be
done with its APIs working on top of our regular date and timestamp
types, could you elaborate?
[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BybW0LJuLtj3yAUsbOw3DrzK00pGk8JyfpCREzi_LSsg%40mail.gmail.com#393d827f1be589d0ad6ca6b016905e80
