[Development] Calendar Systems proposal

[Thiago Macieira]

On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote:
> > I don't expect the calendaring system to require any changes to QDate
> > internals. It stores a Julian day, that's all.
> 
> That's why we need to change QDate. 

If you change QDate's internals, you have to wait for Qt 6.

You can add to its API before then, though.

> The idea is to remove all calendar
> calculation code out of the QDate (into QCalendarSystem possibly). I think
> QDate already has been bloated and knows more that it needs. Consequently,
> there is no chance to add other calendaring API into QDate, and I think
> it's wrong to add such implementation to QDate. My view of QDate is this:
> QDate represents a day in time. So it only needs to know what day it is
> (how many days are to the day 0).

No chance of that ever happening. QDate will continue to support Gregorian 
day, month, year, as well as ISO weeks. Support for other calendaring systems 
(or maybe even other week systems) can be provided by a different class, 
accessible from QDate and QLocale.

> Some of my current changes to QDate are:
> 
>     int QDate::year() const
>     {
>         if (isNull())
>             return 0;
>         int year = 0;
>         // Ask from QCalendarSystem what year we are in
>         year = this->cs.yearFromJulianDay(jd);
>         return year;
>     }

There's no "cs" member and you cannot add one, so the above would be:

	return QCalendarSystem::gregorian(*this).year();

> And also added two methods. This way I'm getting something like:
> 
>     int main(int argc, char *argv[])
>     {
>         QCoreApplication a(argc, argv);
>         QDate date;
>         date = QDate::currentDate();
>         date.setCalendar(QCalendarSystem::Jalali);

You can't add this method.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center