>
> 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. 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).
For example, QDate knows how many days are in a month, what are month names
(in case locale is not present), how to find leap years, and how to convert
a JulianDay to year, month and day in Gregorian calendar. Well, I think it
should only keep a Julian day, and (possibly) a handle to some external
resource (may be QCalendarSystem) that knows about calendar math. This
external resource will tell the QDate how to convert its Julian day to
current calendar. Please let me know if there is anything wrong with this.
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;
}
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);
qDebug() << date.toString("yyyy/MM/dd");
qDebug() << date.toString("dd MMMM yyyy");
qDebug() << date.toString();
return 0;
}
That prints this for me:
Starting
/home/soroush/workspace/build-test-jalali-date-Qt_5_8_0_qt5-Debug/test-jalali-date...
"1395/09/26"
"26 Azar 1395"
"Sat Aza 26 1395"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161217/2bbd0c6a/attachment.html>