Date/Time in KF5 / Qt5

[John Layt]

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.