Re: Extension development

On Fri, Aug 16, 2019 at 10:55 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
> On 08/15/19 02:58, Yonatan Misgan wrote:
> > From this source code how can I get only the year to convert my own
> > calendar year. I need this because Ethiopian calendar is totally differ
> > from GC in terms of day, month and year.
>
> I find myself wondering whether getting only the year is sufficient to
> do the conversion. There is already an Ethiopic calendar available for
> Java (not included, but in org.threeten.extra[1]), and it seems to say
> the years do not align precisely with Gregorian years (as I would not
> have expected anyway):

I can't think of a single reason not to use ICU for this. It will
handle every kind of conversion you could need here, it's rock solid
and debugged and established, it'll handle 10+ different calendars
(not just Ethiopic), and it's already linked into PostgreSQL in most
deployments.

Obviously if Yonatan wants to write his own calendar logic that's
cool, but if we're talking about something that might eventually be
part of PostgreSQL core, or a contrib module shipped with PostgreSQL,
or even a widely used popular extension shipped separately, I would
bet on ICU rather than new hand rolled algorithms.

> "Dates are aligned such that 0001-01-01 (Ethiopic) is 0008-08-27 (ISO)."
>
> So it seems more likely that you would need a calculation involving the
> year, month, and day ... or even that the Julian day number already
> stored in PostgreSQL could be the most convenient starting point for
> the arithmetic you need.

Indeed. I think you should convert between our internal day number
and date components (year, month, day) + various string formats
derived from them, and likewise for the internal microsecond number
that we use for timestamps. I think it's probably a mistake to start
from the Gregorian y, m, d components and convert to Ethiopic y, m, d
(conversion algorithms that start from those components are more
suitable for humans; PostgreSQL already has days numbered sequentially
along one line, not y, m, d). Or just let ICU do it.

--
Thomas Munro
https://enterprisedb.com