Hi, This is the second email in the series of three looking at KLocale in Frameworks 5. This email covers Date/Time, so I have also cc'ed the PIM mailing list for their input.
As with QLocale, the lack of features in QDateTime has forced KDE to create our own solutions such as KDateTime, KLocalizedDate and KCalendarSystem at the cost of interoperability with pure-Qt code. In KF5/Qt5 I want to work to resolve this problem by implementing full support for our required features in Qt. The discussions held at QtCS were very promising on being able to achieve this. You can find the notes at http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/QDateTime Time Zones: A feature everyone wants but no-one seems to have the expertise or time to do. The general consensus was that a new QTimeZone class was required to be embedded in QDateTime with an api based around the Unix/Olsen time zones, but using the host platform time zone system in the background. This is the same concept as KTimeZone so should meet our requirements. I'll be trying to co-ordinate this, but I need people to step up and take on the implementation. Ideally the authors of our time zone support will be willing to port their own code over, or at least review other peoples code submissions. If not all the most advanced time zone features of KDateTime are accepted we can probably put them into a support class. Calendar Systems: The basic concept has been accepted, but the exact details remain to be worked out, but this is one I'm taking on. A number of associated new features will be added as well. Date formatting: Current Qt formatting support is rather basic, but Qt have agreed that full Unicode CLDR formatting support is desirable which I will work on implementing. This however may not be sufficient for KDE as we currently use POSIX formats, and Qt does not do complex translations for month names (e.g. Arabic). In this case I will implement KDateTimeFormatter/Parser support classes to meet our needs. Duration: A number of Qt community members have a merge request for this already, but I feel it needs some clean-up. It would be great if an experienced KDE eye could look at this as it is likely to end up in Qt5. If all goes well we should be able to drop most if not all of our own date/time code. Those features that Qt choose not to support can be implemented in KDE support classes so long as the core QDateTime class container holds and exposes all the data we need. Plan B if this fails is to simply carry on as before. The signs are however that Qt is willing to let us take the lead in implementing all this. The major disadvantage is like the KLocale/QLocale change it will break source compatibility. We will move the old classes into KDE4Support to ease the transition. Thankfully most of our API and code uses QDateTime and QDate anyway, and most of the method names were deliberately kept the same in KDE and Qt, so it is only formatting/parsing method calls and the time zone api that might need changing. If anyone can spot any problems with the plan, or wants to help with the implementation, please speak up! Cheers! John.
