Important: Please read the Qt Code of Conduct -

Other calender systems in Qt?

  • Hi forum

    I have two question about calender system and QDate/QDateTime pair...

    I'm working on a library for "Persian calender": system. (Jalali calender is the official calender in Iran and Afghanistan. Its also widely common in Uzbekistan, Tajikistan and Turkmenistan). This library library uses the 33-years algorithm to convert Julian and Gregorian dates to Jalali vice-verse. It's working fine for both official and scientific Jalali calenders.

    There are two classes in library QJalaliDate and QJalaliDateTime (yes, I'm aware of inappropriate naming...) It's not a pair of wrapper class of QDate and QDateTime. for example for addDays, member function, one may convert Jalali date to Gregorian, add days to Gregorian, convert Gregorian to Jalali and finally return result. This library is not written following that approach. All algorithms are re-write or same as QDate/QDateTime code.

    My first question is if Jalali calender is appropriate to be a part of official Qt or not? Personally I think it worth to be in Qt. many people in world use this calender and it's official in two countries with total population of 105 million.
    If so I would like to commit changes to Qt repository hopefully :) . If not I'm gonna publish as a third-party lib.

    Trying to insert code into my Qt sandbox, I make an exact copy of QDate/QDateTime and changed content. I noticed that the QDate/QDateTime are widely used by forward declaration in many places. And they're not supposed to be a base class of any other class to make a different date object for another calender system. So, in order to add my QJalaliDate/QJalaiDateTime to Qt, I had to explode related codes: add two new types to QVariant, add stream operators for QDebug, add some operators to QLocale and QSystemLocale, etc. It's obviously the wrong way...

    My second question is how to add a new class to Qt for a new calender system avoiding the wrapper approach? It should provide all features of QDate/QDateTime of course ;)

  • Moderators

    Expand the base classes. Try posting this on Qt Development mailing list, there you can get help and advice from guys who make Qt happen.

    Did you take a look at how date and time looks like in Qt5? There are some changes there, but I don't remember exactly what they were.

    Qt5 is feature frozen, by the way, so a merge into 5.0 is probably impossible a this stage. You would have to craft your changes carefully so that they don't break the ABI, and can be integrated into 5.1.

  • Qt 5.1 ! It's too late :( Actually I'm planning to commit it on 4.8.3!

  • Moderators

    4.8.3 is also frozen, and is due to be released in the coming week or two.

    Tough luck, mate :) As I've said, ask on dev ML and you may get some answers. Qt4.8.4 is also planned, maybe you can squeeze it there. But 5.1 is far more realistic. Getting code into Qt is not just "hey guys, I've got some nice code here, you want it?", there is a rigorous quality review, testing, and maturity level assertion.

Log in to reply