Re: glib time functions

[Ali Abdin <aliabdin aucegypt edu>]

* Owen Taylor (otaylor redhat com) wrote at 09:13 on 01/12/00:
> 
> 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.

I don't think so, because the default will be the "normal" ramadan schedule
(which is frequent). Programmers can just ignore this function unless they
/really/ want exact precise dates. This API function would just be a "hook"
for an app to handle the determinism issue itself.

It beats Windows (which ignores this issue entirely).

> 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.

I think that is crufty. People will not update it "automatically" (from where
will they get this info???)

I also think people will just forget about this file, or that it won't even be
updated in glib on a frequent purpose.

Also - this file will have the same limitation as using the API function (it
should only work for the /current/ year). There is no accurate or
comprehensive source of Ramadan schedules in the past. Anyway, if you decide
you still want this approach it should technically be a 'per locale' file
because each country uses something different (we can just use the standard
locales I think (ar_EG for Egypt, ar_SA for saudi arabia, ar_KW for Kuwait,
etc.)


Regards,
Ali