[Development] Calendar Systems proposal

Soroush Rabiei soroush.rabiei at gmail.com
Fri Jan 13 15:07:32 CET 2017


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

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.
3. Number of months in all years are fixed.

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.

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

Cheers,
Soroush



More information about the Development mailing list