Re: Islamic implementation query
- From: Ali Abdin <aliabdin aucegypt edu>
- To: djcb dds nl
- Cc: gtk-devel-list gnome org
- Subject: Re: Islamic implementation query
- Date: Sat, 02 Dec 2000 14:28:36 -0200
* Dirk-Jan C. Binnema (bulkmail dds nl) wrote at 14:06 on 02/12/00:
> Hi Ali,
>
> On Sat Dec 02, 2000 at 12:53:28AM -0200, Ali Abdin wrote:
> -> I began implementing a glib "drop-in" for Islamic calendar support. I have
> -> some questions though.
>
> I doubt whether glib is a suitable place for the Islamic calendar
> stuff. IMHO, it's far too non-general. I think you (or someone else)
> even said the calendar isn't used so much in daily life, but is
> mainly for religious purposes. This is not to say that some library to
> calculate Islamic dates isn't useful to some people - it's just that I
> don't think it belongs in glib, just like function for calculating
> Eastern dates, the times of (sun|moon|...)rise and set etc. shouldn't
> be in. So why don't you make a separate library?
Because I think the place for it is in glib. glib already has general purpose
functions for Gregorian/Julian date manipulations. It makes sense for it to
have the same support for other calendars that are already in-use out there.
You may say "well there are no applications that use islamic date functions".
Thats because there is no support for it out there.
Creating a library won't be a good solution either because people won't want
to link to it (another dependency, don't want to go to the bother to support
it, etc.)
Also, have it in a place like glib makes it kind of like an 'authorative'
source for Islamic date manipulations (so instead of each person going otu and
implementing their own Islamic calendar algorithms (which would be buggy),
there is a one place with a non-buggy version).
Imagine what you would have without Gregorian date functions in glib??
Everyone would be doing their own thing and messing up leap years (such as
2000 being a leap year and 1900 not being a leap year) - and i'm sure there
would be other mistakes too.
There are also political benefits to getting Islamic calendar support into
glib. I could point out to people that glib/Gtk+ 2.0 not only supports Arabic
characters, and RTL to widgets - but it also supports Islamic dates! Right
now, only Microsoft supports Islamic date functions, and Arabic (which is why
99.9999% of people in the Middle East use it).
Yes, it is true that the Islamic calendar is only used mainly for holidays
nowadays. But this is still important (because holidays are part of everyday
life (kind of like "well, I need to know when xmas is"). Also, there are
"official" functions where the use of Islamic calendar is important. For
example, the government and newspapers (newspapers use both Islamic calendar
and Gregorian). There are also other possible uses for Islamic calendar
support (religious scholars, students who write or use software). Applications
like evolution could also use it (sure I could put this stuff in evolution,
but then all the other apps out there won't get the added benefits). Saying
that it is not useful is just plain wrong. I can still list out more examples
where having this in glib will be useful.
I think it is reasonable to have date manipulation functions for Gregorian,
Julian, ISO, Hebrew, Islamic. These are the only "mainstream" date stuff used
today. I would agree that implementing something like an old Mayan calendar
would be "far too non-general".
And please note, just because you don't find it useful, it does not mean
others out there will not find it useful. If you don't find it useful you can
just ignore it.
Regards,
Ali
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]