[Development] Calendar Systems proposal

[Edward Welbourne]

Soroush Rabiei
> Sorry for being noisy on this list, but I think we have several issues
> needed discussion before going further.

I should note that Lars still holds to the view that we should keep this
out of QDate: which seems to imply roughly just upstreaming
KCalendarSystem, albeit with the opportunity to make any improvements we
want in the process.

> First we have a design decision to make, the minimal set of
> assumptions on calendaring systems. According to my minute research we
> can assume following facts on every calendar that is in-use:
>
> 1. All calendaring systems, show dates in three levels: Year, Month and Day
> 2. The week is 7 days. It may start at any of these days.

French revolutionary calendar:
https://en.wikipedia.org/wiki/French_Republican_Calendar
Not that I propose supporting it !

However, it would be best to design a system which doesn't preclude
someone else implementing it.  If we can avoid hard-coding the
assumption of a seven-day week, so much the better.

> 3. Number of months in all years are fixed.

Is there no lunar calendar with occasional extra months ?

> Please let me know about any problem.
>
> Second issue is on CLDR data. I was all mistaken about CLDR. The new
> versions (including v29) include month name data for many calendars
> (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew,
> Indian, Islamic, Japanese and Persian). I managed to modify the
> scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for
> Jalali calendar (named as Persian in CLDR terminology). On the other
> hand, QLocale integration is completed. Now there is `months_data_per'
> array in qlocale_data_p.h and it's working well.
>
> The problem however, is that this data is bigger than what I had in
> mind. Apparently there are many communities using Jalali calendars.
> There are strange month names for Korean, Russian, Turkish and several
> more. (I was expecting data only for Persian and Afghani languages,
> maybe Tajik too...) The array containing month names is 2419 bytes.
> There is also another 6*2=12 bytes per locale in locale's index table.
> considering number of supported locales in qt, we will have 552 * 12 =
> 6624 bytes there and as a result  the overhead in Qt's binary, will be
> 9.043 KB only for Jalali calendar. Islamic civil calendar is almost
> three times bigger if I'm not much mistaken, and I have no idea about
> other calendars. I guess adding five calendars will blow QtCore up to
> 5~7 Megabytes.

Not something we want to impose on all users of Qt.

> I have changed qlocalexml2cpp.py such that it generates data for each
> calendar in a separate array. So it can be excluded by preprocessor
> directives. My suggestion is to make calendaring support,
> configurable, and provide data only for Gregorian calendar by default.
> And also we can give users the option to choose among locales they
> want to include in their builds:
>
>     ./configure -developer-build -opensource -confirm-license -debug -calendars gregorian,persian,islamic_civil

That sounds reasonable.  Another approach might be to design a
plugin-based architecture - with similar config, but controlling which
plugins get built.  This would make life easier for anyone who wants to
add a calendar system we don't support: they'd just need to add their
plugin to wherever we put ours.

        Eddy.