Hi Thomas On Mon, Mar 15, 2021 at 2:58 PM Thomas Munro <thomas.mu...@gmail.com> wrote:
> > One key question here is whether you need a different date type or > just different operations (functions, operators etc) on the existing > types. > > I am thinking of having a converter to a specific calendar after each operation and function for display or storage. It works on Ethiopice calendar and i expect it will work on other calendar too > > 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? > > Ethiopice calendar have 13 months so it can not be stored as date and timestamp type and you approach seems more complicated and i suggest to have this feature on the purpose of PostgreSQL popularities too not only for my 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. > > Each calendar-aware date arithmetic is different so solving one calendar problem didn't help on other calendar > > 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... > I think you suggesting this by expecting the implementation is difficult but it's not that much difficult once you fully understand Gregorian calendar and the calendar you work on > > 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 I don't know how you see this but for me the feature deserves a specialist and it is not that much difficult to have one because i guess every majore calendar have english documentation regards Surafel