[Development] Calendar Systems proposal

[Edward Welbourne]

I observed:
>> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has
>> secular society shifted the day boundary to midnight in practice ?

Soroush replied:
> Indeed they do the simplification needed to adopt modern lifestyle.

OK, good - then we have an excuse to keep the simple model !

> As far as I know, modern lunar calendars being used in ME as official
> calendars, have loads of simplifications applied compared to the
> original calendars. The start of a month in Islamic calendar in Fiqh
> (regional calendar) is based on observing new moon (by unaided eye) in
> the sky. That's why Saudi Arabia sometimes celebrate end of Ramadan
> one day after Turkey, and one day before Iran. That's why number of
> days differ from a year to another.

All of which argues for us to support the simplified official version,
while making it possible for apps and user-communities to add in their
own implementations taking account of local quirks.

> Though, the start of the day is 00:00 in modern calendars. And number
> of days in months are fixed.

That, at least, is reassuring ;-)

> Anyway, the only country using lunar calendar (Saudi Arabia) just
> switched to solar system (Gregorian). But we have to support Islamic
> calendar (modern version) of course.

Indeed - even if it's not the official state calendar, there are folk
still using it who shall want their software to respect that.  We can
make that *possible*, even where we aren't going to do all of the
work ourselves ...

> My current implementation looks like KCalendarSystem with some
> differences. Calendar classes are subclassed from QAbstractCalendar,
> and have to implement several methods. I tried to make this class as
> generic as possible, there is no assumption on month days and number
> of months.

Sounds promising.  If you can push it to gerrit as a work in progress
(start the subject line of the commit message with "WIP: " and the
system shall know what you mean; you can also push to refs/drafts/dev to
make it a draft review, until you eventually push to refs/for/dev to
turn it into a "real" review), I'll take a look at it and we can discuss
more there (taking traffic off this list).

I was tidying up in our Wiki after wearing out my brain on Friday and
stumbled upon [0], a 2011 write-up of relevant ideas - written by John
Layt, who is the author of KCalendarSystem.  (Speaking of: if anyone is
in touch with him and can reach him other than via his @KDE e-mail,
which I've pinged, please do bring this discussion to his attention.)
It may be a source of some fruitful insights.

[0] https://wiki.qt.io/Qt-contributors-summit-2011-QDateTime

> I just finished adding new methods to QDate and it's working for
> Jalali Calendar.
>
> QDate d = QDate::currentDate();
> int gyear1 = d.year();  // 2017
> int gyear2 = d.year(QGregorianCalendar);  // 2017
> int jyear1 = d.year(QJalaliCalendar()); // 1395
> int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395

Nice.  I interpolate a missing () on the end of QGregorianCalendar().

> I didn't touch Gregorian calculations in QDate, just added more
> functions. Does removing static members count as an ABI change? I'm
> planning to move all the math out of QDate into QGregorianCalendar.

A static function is invisible to anything outside its own compilation
unit, so turning assorted static functions in qdatetime.cpp into methods
of QGregorianCalendar is entirely feasible.  You can even mess with
QDateTimePrivate - see the warning comment in qdatetime_p.h ;^>

Static members of a public class, however, have to stay (I suppose).
Not that you have to continue *using* them, if something else makes them
redundant ...

> About calendaring widgets, The widget obviously needs to keep
> information on what calendar system it uses. I think it's possible to
> add members to private API classes? After all it's **private** and
> there's only a pointer to private API class in main class. So it would
> be A[BP]I compatible I suppose.

Check for that warning comment, or a header-name ending _p.h - you can
get away with plenty of change there.

> And also we need to add some functions to main class:
>
>     void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString?
>     QAbstractCalendar* QDateEdit::calendar() const; // meh...

Those make sense.  Definitely pass QAbstractCalendar * to the setter;
otherwise, client code can't supply a custom calendar that's not known
to our abstract base class's method.  The advantage of an overload
taking QString is minor - it'll package a call to fromName - and I fear
it would add confusions, with folk expecting too much of it, or a
matching getter returning QString.

Please keep QDateEdit changes in a separate commit from QDateTime
changes; ideally, even separate the creation of QCalendarSystem's base
class (at least) from re-working QDateTime to break out
QGregorianCalendar.

> There is another issue: How do we add calendar localization to QLocale?

I don't know.  However, [1] may offer some insight; albeit [2] is
similar and says the plan outlined there was abandoned - two more finds
from Friday evening.  The latter links to a blog post, by John, from
2012 - as a hint to how old these are.

[1] https://wiki.qt.io/Locale_Support_in_Qt_5#QCalendar
[2] https://wiki.qt.io/Qt_5_ICU

	Eddy.