Thread: Multi calendar system for pgsql

Mohsen Alimomeni <m.alimomeni@gmail.com> writes:
> I want to try to add a multi calendar system for pgsql. I want to know if it
> will be accepted as a patch to pgsql?

There's probably about zero chance of accepting such a thing into core,
but maybe you could do it as an add-on (pgfoundry project).

> For implementation I think it is better to add this support in date fields
> like this:
> create table tb (dt date calendar persian);

Consider specifying the calendar as a typmod, eg
create table tb (dt cdate(persian));

since the necessary extension hooks already exist for that.
        regards, tom lane

> I want to try to add a multi calendar system for pgsql. I want to know if it will be accepted as a patch to pgsql?
> 
> More details:
> Multi calendar systems are useful for several languages and countries using different calendar: Hijri, Persian,
Hebrew,
> etc.
> For implementation I think it is better to add this support in date fields like this: 
> create table tb (dt date calendar persian);
> if no calendar is defined, it will be Gregorian so no problem is made for old sql commands.

I don't think that new keywords should be added for that if it does not 
belong to the SQL standard, especially with something as open ended and 
sensitive as a cultural related keyword: there are dozens calendars listed 
on wikipedia...

ISTM that this is either a localization problem, possibly fully 
independent from pg, or a conversion issue with a simple function which 
may be develop as an extension outside pg, say:
    SELECT PersianDate('2008-02-18'::DATE);


-- 
Fabien.

On Wed, Feb 18, 2009 at 07:50:31PM +0330, Mohsen Alimomeni wrote:
> Multi calendar systems are useful for several languages and countries using
> different calendar: Hijri, Persian, Hebrew, etc.

When would the differences between these calenders actually show
up?  I can only think of it affecting input/output routines and the
date_part,date_trunc,to_date and to_char routines.  But am I missing
something?

If that's all, then how about just treating the current PG
date types as Julian days (as far as I know, that's how it's
treated internally anyway) and providing a multi-calender set of
date_part,date_trunc,to_date and to_char routines.  I.e. leave out the
input/output routines.

Doing this would be much easier, but less fun, than creating whole new
types and having to modify the parser as well to recognize the new
syntax.

--  Sam  http://samason.me.uk/

m.alimomeni@gmail.com (Mohsen Alimomeni) writes:
> I want to try to add a multi calendar system for pgsql. I want to
> know if it will be accepted as a patch to pgsql?

I would expect there to be nearly zero chance of such, at least in the
form of a change to how dates are stored.

As long as there is commonality in epochs and some continuity of
calculations of dates relative to epochs, there shouldn't be any
fundamental problem in adding on functions to do the following sorts
of things:
- Calculate what the UNIX date is for a given date in a given  calendar
- Output a UNIX date in the form indicated by a given calendar

You should avail yourself of the book, _Calendrical Calculations_, by
Edward M Reingold and Nachum Deerschowitz; it presents details of
calculations and conversions of dates between the following calendars:
- Gregorian- Julian- Coptic- Ethiopic- ISO- Islamic- Hebrew- Ecclesiastical Calendars, for dates of Christian holidays
suchas Easter- Old Hindu- Modern Hindu- Mayan- Balinese Pawukon- Persian- Baha'i- French Revolution- Chinese
 

It would seem a whole lot preferable to create functions like (and
there may be better names!):
create function parse_date (locale, text) returns timestampcreate function output_date (local, timestamp) returns text

Thus, you might expect the following:
 select parse_date('Islamic', 'Miharram 1, AH 1');
parse_date
-------------------------622-07-16 00:00:00

Or
select output_date('Persian', '622-03-19'::timestamp);
output_date
-------------------------1 Farvardin AH 1

(It is entirely likely that I'm fracturing spellings of things!
Apologies if I am!)

http://emr.cs.uiuc.edu/home/reingold/calendar-book/index.shtml
-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://cbbrowne.com/info/x.html
"Thank you for calling PIXAR! If  you have a touch tone phone, you can
get information or reach anybody here  easily!  If your VCR at home is
still blinking '12:00', press '0'  at any time during this message and
an operator will assist you."
-- PIXAR'S toll-free line (1-800-888-9856)

Mohsen Alimomeni <m.alimomeni@gmail.com> writes:

> Hi,
> To implement my local calendar, I tried adding a new type (pdate) to pgsql
> as an extension. At first I used a struct of size 6, and I returned a
> pointer to it in pdate_in with no problem. Now I changed the type to int32,
> returning PG_RETURN_INT32. I removed all palloc calls. but the server
> crashes with segmentation fault before returning in pdate_in.

You want to set PASSEDBYVALUE

(And you probably want to adjust alignment though I don't think it's causing
any problem aside from wasted space)

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!