> > 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"
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development