Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)

[Stephen Kelly]

David Jarvie wrote:

>>
>> Anyway, I've started a page to document such things at
>> http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
>> David Jarvie, could you add something to the KDateTime entry?
> 
> Done. I hope it contains enough explanation - if you think it needs more,
> please say so.

I'm not sure the intention should be a wholesale merge of KDateTime into 
QDateTime or something similar to that. Some of the features and APIs in 
KThing classes are a direct result of being outside of the Qt APIs. I think 
the question should be: 

What is the minimum of changes needed to QDateTime such that it can be used 
as a data transfer class by KDE? 

Currently as far as I know, QDateTime simply strips any timezone 
information, so that's a must. I'm not very familiar with KDateTime but 
looking at the API, the rest is comparators (we could have a 
KDateTimeComparator), time delta (daysTo, potentially replacible with 
http://qt.gitorious.org/qt/qt/merge_requests/1014), and different formats 
(KDateTimeFormatter?)

Or all that stuff could stay in a class called KDateTime, but be repurposed 
not to be a data transfer class of datetime+timezone info, but a features, 
functionality and convenience class. If KDateTime were no longer a data 
transfer class we could use QDateTime in our APIs instead of KDateTime, 
which would mean our APIs would be compatible with other Qt APIs and 
therefore usable together.

The QDateTime + timezone stuff is in motion right now, so it's a chance to 
see if it can suit the needs of KDE and not just QtMobility. If you have 
extra input I'd encourage you to make it on that bug report.

http://bugreports.qt.nokia.com/browse/QTMOBILITY-1139