Islamic Calendar - Technical Implementation

For the past few days, I have been researching a lot about the astronomical calculations that are going to be used for the Islamic Calendar. The research has been documented from the following sources, namely:

• Calendrical Calculations: Third Edition - Nachum Dershowitz and Edward M. Reingold
• Notes and Errata on Calendrical Calculations: Third Edition - 25th May 2011
  
• Astronomical Algorithms: First Edition - Jean Meeus
• Practical Astronomy with your Calculator: Third Edition - Peter Duffet-Smith
• How to compute planetary positions - Paul Schlyter

The amount of calculations required for the complete implementation of the calendar are highly extensive, and require very high precision. Without the astronomical calculations, the Islamic Calendar lacks accuracy by 1-2 days and therefore it becomes difficult to predict future dates in the Islamic Calendar. The astronomical calculations are so precisely timed that such an ambiguity in the prediction of dates of the Islamic Calendar is reduced to 1 day in 2500 years. As we have discussed earlier, that the lunar crescent visibility serves as an important criteria in determining the precise Islamic Calendar, we shall be defining the necessary functions that are required to calculate and successfully implement the astronomical calculations in the Islamic Calendar.

The astronomical files will be defined based on the considerations of time and astronomy as deducted from the theoretical research.

astro.h
This header file would contain the general functions for astronomical calculations. The functions perform calculations for converting time between different formats, for calculating Julian centuries and the ephemeris correction, for calculating significant moments of the day that have astronomical significance and polar-coordinate conversion. The following member functions would be implemented:

• zoneFromLongitude()
• universalFromLocal()
• localFromUniversal()
• standardFromUniversal()
• universalFromStandard()
• standardFromLocal()
• localFromStandard()
• ephemerisCorrection()
• dynamicalTime()
• julianCenturies()
• equationOfTime()
• apparentFromLocal()
• localFromApparent()
• siderealFromMoment()
• obliquity()
• declination()
• rightAscension()
• approxMomentOfTwilight()
• momentOfTwilight()
• dawn()
• dusk()

astrosolar.h
Astronomical calculations which relate to various aspects involving the sun would be performed by the functions defined in this file.

• nutation()
• aberration()
• solarAnomaly()
• solarLongitude()

astrolunar.h
Out of all the heavenly objects that are visible in the celestial sphere, the moon is perhaps the most beautiful of them all. It is also, one of the most hardest to correctly determine it's position and various other astronomical aspects. This header file will be defining the functions which will be used in the astronomical calculations which relate to the moon.

• lunarCorrection()
• nthNewMoon()
  
• meanLunarLongitude()
• lunarElongation()
• lunarAnomaly()
• moonNode()
• lunarLongitude()
• lunarLatitude()
• lunarPhase()
• lunarDistance()
  
• lunarParallax()
• lunarAltitude()
  
• lunarAltitudeTopocentric()
• visibleCrescent()
• lunarPhaseBefore()

All the astronomical calculations required to correctly calculate the Islamic Calendar have been defined in aforementioned header files.

As the project would progress along the time-line, the necessary functionalities required by the other calendar systems could be easily appended/modified/implemented in these files.

The Calendar
Most of the code required in the astronomical Islamic Calendar is similar to the Islamic Civil Calendar, with the difference that the lunar crescent visibility criteria affects the 'day' in both the calendars. The astronomical calendar would be derived from kcalendarsystem.h and would include functionalities to modify the date according to the crescent visibility. The crescent visibility will be implemented mainly through the function lunarPhaseBefore() defined in astrolunar.h.


However, one particular area that I haven't been able to figure out yet, that is, the way in which I am supposed to handle the locale argument for the functions. Many functions use their calculations depending on the latitude and longitude of the locale. KLocale, however, does not define the latitude and longitude in its locale object. The longitude of the locale could be determined by the local time (or time zone) specified in KLocale. To work around the latitude, we might have to manually tabulate the values according to the country (or country code).