Category Archives: Hijri Calendar

Proposal for Hijri Date Synchronization Standard and Protocol

Hello all,

This proposal mainly focuses on the request for Hijri date synchronization standard and its protocol.

Note: synchronization means here synchronization of clients date with the actual date from the suggested service.


1. Currently the Hijri calendar is based on conversion algorithm using Gregorian calendar. This conversion is inaccurate since Hijri calendar is lunar based.

2. Each Islamic country may have a different local Hijri date, this date usually synchronized with Saudi Hijri date by Zo-ElHeja month because of Arafa day and Eid-Adha.

Problem description:

1. The normal end user of today OSs, Applications can’t get an accurate Hijri date using the current infrastructure and technology.

2. Application developers can’t use a reliable method to know the actual Hijri date value. Instead, nowadays, most application developers and web sites (e.g. Aljazeera, CNN, etc.) set this value every daily with the correct Hijri date. This manual setting can cause silly mistakes and consumes some effort.

3. Currently there is no formal way to know the Hijri date in other countries. Of course the user can look into some on-line news papers in this country but this is manual, slow and may be difficult sometime. Also this is not automated. Automation is needed to allow integration of the Hijri date in computer systems.

4. Currently there is no way to convert the hijri dates across different countries. In other way, if we have 2 Muharram in Egypt, sometimes it is needed to know what is the current Hijri date in India. For example to allow reliable usage of Hijri calendar. Reliable usage means that if someone sets a meeting in specific Hijri date (2 Muharram), it will appear to each participant in the meeting in his own local Hijri calendar (say 3 Muharram in India).

5. If Hijri calendar is inaccurate , conversion between Gregorian and Hijri will be inaccurate as well, so missing for accurate Hijri date is really bad thing in computers systems that need to be fixed to make it more reliable and hence allow it to be used by users.

6. Technology and G11n should support and respect Islamic culture and calendar, instead of forcing people to use other calendar systems. Also we need to remember the following Aya in Quran. Our responsibility is to allow technology to support Hijri at least to remove any claims by end user like saying that the lack of Hijri support in the technology prevents the Hijri usage.

{إِنَّ عِدَّةَ الشُّهُورِ عِندَ اللّهِ اثْنَا عَشَرَ شَهْرًا فِي كِتَابِ اللّهِ يَوْمَ خَلَقَ السَّمَاوَات وَالأَرْضَ مِنْهَا أَرْبَعَةٌ حُرُمٌ ذَلِكَ الدِّينُ الْقَيِّمُ فَلاَ تَظْلِمُواْ فِيهِنَّ أَنفُسَكُمْ وَقَاتِلُواْ الْمُشْرِكِينَ كَآفَّةً كَمَا يُقَاتِلُونَكُمْ كَآفَّةً وَاعْلَمُواْ أَنَّ اللّهَ مَعَ الْمُتَّقِينَ} (36) سورة التوبة


1. Create a standard centralized service to be publicly available to allow synchronization of the hijri date based on the country, also use Hijri date of Makka as a standard unified date. ( I suggest the name “Internet Hijri Service(IHS)” or “Internet Synchronization Hijri Service (ISHS)”)

2. We will need to write a standard protocol to describe the communication between the requester of the service and the provider, also this define the request format/information needed and the response format/information.

3. We may need to define various formats for the request and response that can be used out of the box, like html div, xml, plain text, Java, RPC etc.

4. It might be useful to provide a service that return names of  a group of countries whom share the same specific Hijri date.

5. We need to request adding such service to Hirji date adjustment in OSs like Windows, Linux OS, Solaris, AIX, AS400, etc. Also Eclipse SWT, .Net and Java should have the APIs to get the Hijri date for a specific country, may be based on the locale object.

6. We need to find a way to add this service to the Unicode CLDR, may be adding the Hijri date format tag that should be updated automatically using the standard protocol. (This may need more discussion if this is not possible, and also this can be delayed until we have something solid).

7. We need to add another conversion service to the standard protocol which return the equivalent Gregorian date of any Hijri date, and the equivalent Hijri date of any Gregorian date, this is very important to make Hijri calendar a reliable date that can be accurately converted to and from Gregorian date.

Some applications:

1. Some application will be possible and reliable based on this standards protocol and service like: Religious Events (Eid Fetr, Eid Adha, First Day in the Hijri Year,  AAshora,  Maweld Nabawy,  1st Ramadan, etc.) which can be integrated based on the user local in current schedulers applications like Calendar applications which define working days but can’t understand the current Islamic religious holidays and events unless defined manually which is a usability issue, OSs like Windows, Linux can also use such religious events smartly, ICU Hijri calendar can be updated to allow it as interface to adjust the Hijri date from the public service before return the date to user (if  internet access available otherwise it will keep using  current way based on conversion from Gregorian)

2. This service will allow Hijri date reliable use in set a meeting with different people (in same country like Egypt) using local Hijri calendar instead of Gregorian, so for example I can set a meeting to meet people on 24th of Muharram. Setting meeting using Hijri calendar will be highly reliable when set for any date of the current month (i.e. Hijri month already determined)  (note that current implementation of Hijri calendar doesn’t allow this because it does not use accurate Hijri date). The same reliability is available to set old events or dates. For example sometimes you need to set the dates of your travel period or travel expenses (and similar cases), While it is not highly reliable to set the date out of the current Hijri month. For example, set a date 20 Saffar (assume Saffar is the next month) should have it is etiquette between users, which mainly allow 1 day adjustment that the system will does automatically for all invitees at begin of this month (i.e. Saffar) and send a reschedule of this meeting  automatically (if needed) so users can accept the new confirmed and reliable date based on the actual start of this month (i.e. Saffar). This is unavoidable way to make the Hijri calendar reliable for months in future (note that this is not an issue when using a date in the current Hijri month as described before).

3. Web sites can use this service to reliably display the current Hijri date for specific country. So a web site like doesn’t have to set the date manually every day. Also it is now possible to display the Hijri date according to the visitor not according to server local Hijri date (e.g. Local date in Qutar for which may be needed sometimes. Think of the method that  allow web sites to display the time in your own local time not the server time, also think of a congratulations message that can be displayed to user at specific Islamic events according to his country today Hijri date.

4. The reliable conversion of Hijri data to Gregorian and vice versa, allow other countries, embassies, etc. to use Hijri calendar in their communication (beside Gregorian) not worry about set wrong Hijri date for Egypt OR for Suadi Arabic ..etc.

5. We may think of many applications but this is what I thought about for now and I’m sure this can be expanded to include Office docs Hijri dates, Quote of the day applications, Visa and accounting application especially for Saudi Arabic, etc.

Please let me know if you have additions and so we can formalize this proposal and initiate it to one of the standard organization, may be ISO or ECMA or may be establish separate organization for it.

Leave a comment

Posted by on 17/06/2010 in Hijri Calendar, Proposal