john.layt.net

Another update on the Calendar Systems.  Last time I mentioned I was moving onto the Bahai'i calendar.  Well, that proved to have some problems (see below) so I moved on to something easier, the Ethiopian and Coptic calendars which will be 4.4.  These are nice, straightforward calendars based on the ancient Egyptian calendar.  These have 12 months of 30 days followed by a separate epagomenal period (effectively a short 13th month) of 5 days or 6 days in leap years which are every 4 years, which makes the whole calculation very simple indeed. 

The only differences between the Ethiopian and Coptic calendars are the epoch and the names of the months and weekdays, so it's effectively a two-for-one deal.  The hardest part was finding the right English versions of the Coptic and Ge'ez names, which I hope I've got right as there were several versions to choose from (quick apologies to the translators for forgetting to give them a heads-up on the tricky strings involved).  I don't know what the FOSS market-share is in the Ethiopian or Coptic communities (Google doesn't reveal anything much), and we don't have a Ethiopian translation project, but it's one less barrier they might have to negotiate in the future.  It's highly unlikely we will ever have a Coptic translation with only 300 speakers worldwide, but the calendar itself has a wider use.

Pics of the Ethiopian and Coptic calendars, notice the short epagomenal period showing in the Coptic one.

Funnily, while OSX has locale support for different calendar systems including both Coptic and Ethiopian, Apple's own app programmers don't seem to have got the memo, spot the bugs in iCal:

One bug we did have that I've fixed for 4.4 is RTL support in the Plasma calendar table:

The Bahai'i calendar proved harder than I expected.  It's interesting as it has 19 months of 19 days each, and a separate epagomenal period of 4 or 5 days.  That would be easy enough, except the epagomenal days are not at the start or end of the year, they are placed between the 18th and 19th months and in practice appear to be written down as month 0.  So how do we do that?  We could just label the epagomenal days as month 19 and month 19 as 20, which is good maths but bad usability, as would treating the epagomenal days as part of the 18th month.  It seems there's going to have to be some magic going on between the user interface and the actual calculations, but that could mean every widget that shows/reads dates will need rewriting to know what to do.  Nope, that's out too.  In emacs they treat them as prefixing the 19th month, so are entered as negative days in the 19th month, i.e. -03/19/2009, which would break all our existing validation and formatting code.  Which is about when I gave up and moved on to something easier :-)

In the comments on my last blog, someone mentioned that supporting the Japanese Emperor Era calendar should be easy as it is just the Gregorian Calendar but with the year instead of being counted since the nominal birth of Christ (i.e. AD)  being the number of years into an Emperors reign.  If only it were that easy :-)  The big problem is that everything in KCalendarSystem assumes an 'absolute' year' in a continuous integer range from -9999 to 9999 (with an optional year 0), we make no allowance for the entry or display of an era for the year to start counting from, nor does the C/POSIX format codes have a value for era.  Supporting Era style calendars would require adding new virtual methods to the API for era() and eraYear(), code to convert between era years and absolute years, and changes to the date reading and formatting code to do the translation.  That's a problem, as the KCalendarSystem base class has no virtual table slots left to add new API.  There's ways around that, but it's going to take careful planning.

Finally, I've started planning for the lunar calendars in 4.5 by purchasing a copy of the bible of astronomical calculations which has special chapters devoted to calendars.  I need to determine exactly what calculations we need to be able to perform, and how complex they are to implement and support.  If they're relatively few and simple, then we can have our own or borrowed implementations directly in kdelibs, if not we need to either find existing implementations to (optionally) depend upon, or work with another project for them to support.  Possible sources of code include KStars, the Plasma sunrise/sunset data engine, or libnova (which KStars already uses).  Possible new homes could be a version of Marble in kdesupport (if that ever happens?), a separate library in kdesupport, or an outside project like libnova.