RE: Locale support

Thank you for your quick response. I am also impressed to develop Ethiopian calendar as an extension on PostgreSQL and I I have already developed the function that convert Gregorian calendar time to Ethiopian calendar time. But the difficulty is on how to use this function on PostgreSQL as well on PostgreSQL month names are key words when I am developing Ethiopian calendar the date data type is doesn't accept Ethiopian month name as a date data type value only the numeric representation of the months are accepted by compiler.
So my question is after developing the converter function where I put it for accessing it on PostgreSQL.

-------- Original message --------
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Date: 8/8/19 11:34 AM (GMT+03:00)
To: Yonatan Misgan <yonamis(at)dtu(dot)edu(dot)et>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Locale support

On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan <yonamis(at)dtu(dot)edu(dot)et> wrote:
> I am Yonathan Misgan from Ethiopia, want to add some functionalities on PostgreSQL to support Ethiopian locales. I want your advice where I start to hack the PostgresSQL source code. I have attached some synopsis about the existing problems of PostgresSQL related with Ethiopian locale specially related with calendar, date and time format.

Hi Yonatan,

I'm not sure if this requires hacking the PostgreSQL source code. It
sounds more like an extension. My first impression is that you might
not need new types like "date". Instead you might be able to develop
a suite of functions that can convert the existing types to and from
the display formats (ie strings) and perhaps also components (year,
month, day etc) that you use in your calendar system. For example:

SELECT to_char_ethiopian(CURRENT_DATE, 'YYYY-MM-DD'), or whatever kind
of format control string would be more appropriate.

However, I see from https://en.wikipedia.org/wiki/Time_in_Ethiopia
that new days start at 1 o'clock, not midnight, so that makes
CURRENT_DATE a bit more confusing -- you might need to write a
function current_eth_date() to deal with that small difference. Other
than that detail, which is really a detail of CURRENT_DATE and not of
the date type, dates are internally represented as a number of days
since some arbitrary "epoch" day (I think Gregorian 2000-01-01), not
as the components you see when you look at the output of SELECT
CURRENT_DATE. That is, the Gregorian calendar concepts exist mostly
in the display/input functions, and the operators that can add
intervals etc. You could supply a different set of functions, but use
the same types, and I suspect that'd be convenient because then you'll
be able to use Gregorian and Ethiopian conventions with the same data,
whenever you need to. It's much the same for timestamps, but with
more complicated details.

I see that there are libraries and bits of example code around to do
the various kinds of calendar maths required for Ethiopian dates in
Perl, Python etc. If I were you I think I'd experiment with a
prototype implementation using PL/Perl, PL/Python etc (a way to
define new PostgreSQL functions written in those languages), and if
that goes well, try writing an extension in C to do it more
efficiently.

The end goal of that woudn't need to be part of PostgreSQL itself, but
just an extension that anyone can download and install to use
Ethiopian dates conveniently.

--
Thomas Munro
https://enterprisedb.com