Jalali Calendar updated

I've almost completed my QA review of the code in the existing Calendar Systems, with the Hijri / Islamic calendar passing relatively unscathed but some possible optimisations noted (it uses recursion where direct calculation may be faster).  The Jalali calendar (aka Iranian or Persian, as used in Iran and Afganistan) has proven somewhat harder and needed a lot of research.

The basic problem is that the Jalali is a purely Solar calendar with the first day of the year being officially defined in relation to the vernal equinox and solar noon at the reference longitude for Iran Standard Time (52°30' E).  There is no offically defined rule for calculating leap years, nor can there be, a leap year is just any year in which there are 366 days between successive vernal equinoxes.  The upshot is there is no simple arithmetic method to calculate when leap years should occur, for complete accuracy you must correctly calculate the vernal equinox.

There are two popular approximations for sequences of leap years, the 33 year cycle and the 2820 year cycle (aka the Birashk method), but these each return wrong results in various and different years, and there is much debate on which is better.  Most implementations choose to use one of these for efficiency and simplicity regardless of accuracy, Microsoft has chosen the 33 year cycle which is more accurate in years immediately around AD 2000, many FOSS projects have gone with the 2820 year cycle due to Emacs implementing it first.  I haven't confirmed which Apple supports.

In KDE we have been using the 2820 year cycle when calculating date conversions, but were using the 33 year cycle when calculating leap years, leading to some quirky errors. I've fixed that to always use the 2830 year cycle, and now restrict the valid date range to the years AP 1244 to 1530 (roughly AD 1865 to 2152), a useful range of modern dates during which the 2830 year cycle is only wrong twice (AP 1404 and 1437, roughly 2004 and 2058).  I've added special exceptions to cover these two cases so we now exactly match the true astronomical calendar for the entire supported period.

In 4.5 we should begin to support astronomical calendars properly, so we will switch Jalali to correctly calculating the equinox and thus extend the supported date range.  We will also provide reference implementations of the 33 and 2820 year cycle calendars to allow for interoperation with systems that use them.

The final calendar for QA is the Hebrew calendar, which looks to have had some bad bugs creep in.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


HI John.
First of all, thanks for your work on calendar systems. Specially, Jalali. This is a killer feature for Iranian KDE users.
Second, could you please explain how exactly you want to support astronomical calendars properly? We are having issues in several softwares we develop. Also this problem stopped jalali support to go inside PHP 5.3 release.
Third, a few months ago when holidays support was added to calendar plasmoid, i tried to add iranian official holidays to it. However, most iranain calendars are based on Arabic (Hijri) dates and holidays. Do you you think there is any workaround for that?


Hi Emil,

Well, I'm still planning the astronomical support, so I can't tell you exactly, but we will implement or borrow code to calculate the equinox and other useful astronomical functions that the Islamic, Chinese, and other calendar systems need.  If you want to see an example of a working astronomical Jalali calendar, then go to http://www.fourmilab.ch/documents/calendar/ where you can play with one and download the javascript code which is in the Public Domain.

It's interesting you mention adding support into PHP, I see also that Gtk/Gnome is planning support in Gtk3/Gnome3, we should probably try co-ordinate to ensure all implementations are consistent!

Non-Gregorian Holidays are something we are also in the planning phases for, we have to design a whole new standard for the definition file and a new library to interpret it for kdepim.  This looks likely for KDE 4.6 not 4.5, so I may try extend the current implementation before then if I can find time. Of course, it depends on if the Hijri holidays are calculated using the civil, astronomical, or observational versions of the calendar and if we support them?  The observational calendar could be an issue, we would need the user to input the observed dates or find an online feed for updates.

I'm also planning support for non-Gregorian recurring events in KOrganizer as well, initially through a hack and then later via proper support in the iCalendar standard. This will require a standardisation effort to properly define the calendars and calculations to ensure correct interoperability.

See http://websvn.kde.org/trunk/KDE/kdepimlibs/kholidays/DESIGN?view=markup and http://old.nabble.com/Non-Gregorian-Calendar-Systems-in-KOrganizer-td267... for more details.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.