Re: glib time functions

[Owen Taylor <otaylor redhat com>]

Ali Abdin <ALIABDIN aucegypt edu> writes:

> On Thu, 30 Nov 2000, Robert Brady wrote:
> 
> > On Thu, 30 Nov 2000, Ali Abdin wrote:
> > 
> > > I'd say ignore it (at least for the time being). Or have a function which we
> > > can set for "early" ramadan or "normal" ramadan schedule or "late" ramadan
> > > schedule. Then GLib could handle it internally.
> > 
> > I think it's better to not handle it at all than to handle it which such
> > flaws.  Better to press the Authorities to introduce a deterministic
> > calendar instead.
> 
> Its now flawed if you take into account the ramadan schedule (which can 
> easily be set with a function).
> 
> i.e. G_RAMADAN_EARLY would detract a day from everything past the ramadan 
> month (9th month). G_RAMADAN_NORMAL (the default) would do nothing, and 
> G_RAMADAN_LATE would add a day.
> 
> I think it can be handled, and in fact it HAS been handled on Windows 
> (which is the dominant software producer in the Middle East).
> 
> If you say "no we shouldn't support it" people are going to go somewhere 
> else that /WILL/ support it. If the non-deterministic calendar is good 
> enough for GNU Emacs, then I think it is good enough for glib.
> 
> To say that it can not be handled is inaccurate (because I have proven 
> that it can). But to say that it /should/ not be handle, I believe, is 
> wrong.

I'm not sure we should be supporting non-western calenders at all
in GLib. If we do, the emphasis should be on ones that are currently
used, so the Islamic calender is a better candidate than 
the Mayan calender or the pre-Gregorian western calender.

I think having an API to adjust the calender is broken - if the
application using it knows about such things it doesn't need
code in GLib.

We probably could have:

 /var/lib/glib/islamic-calender.dat

Which contained the necessary information, and then users that
cared could have a yearly cron job that updated it.

Regards,
                                        Owen