Re: [Development] Calendar Systems proposal
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
>
> 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("/MM/dd");
qDebug() << date.toString("dd ");
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
