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