Re: ITL status

[Djihed Afifi <djihedlists at googlemail dot com>]

Salam Thamer,


> 
> * We need to synthesize the current *two* implementations of Hijri
>   into a single implementation, with less duplication and a better
>   structure. Better yet, we should push for a single de-facto standard
>   in the *nix world for calculating hijri dates arithmetically. I've
>   seen discrepancies in different FOSS projects, but I'm no expert in
>   this, and I'm not sure why we should need or use *two* different
>   implementations without making some things clear (like which
>   implementation is more common and for what location, for
>   example?). Also, someone should investigate how this is being done
>   elsewhere (i.e Microsoft-land with regards to Saudi Arabia and other
>   countries), and how they are dealing with inconsistencies between
>   the actual sightings of the crescent and the arithmetically
>   calculated "civil" calender.

I've encountered on this issue while using ITL's hijri functions.

I've seen quite a few locations that allow manual correction of hijri
date within a [-2, +2] day frame, Including MS Outlook 2003. 

I believe there is no other way to do in ITL given the human imprecise
nature of the Ramadhan's moon sightings. One can "correct" the gregorian
date before supplying it as an argument by adjusting it to produce the
necessary output, but I'd imagine that there is a case for making it
doable within ITL itself by accepting an extra correction argument.

One could hope to allow for syncing the date with a central server, but
that is beyond the scope of ITL. All ITL can do is allow for manual
correction, IMO.

Djihed