Replacement for KDateTime

Alex Merry alex.merry at
Sun Aug 2 12:22:45 BST 2015

On Saturday 01 August 2015 20:47:16 Sandro KnauƟ wrote:
> Hello,
> the kdepim is discussing how we can replace KDateTime inside kdepim
> (primarly kcalcore) . There are some issues, why we can't replace it simply
> with QDateTime.
> * indivual timezone support, this is something that we need when parsing
> ical and have no known timezone information. I havn't looked into it, but I
> think this can make it eventually into QDateTime.
> * dateOnly support is used a lot. In ICAL it differs if you set dateonly or
> datetime. dateonly events f.ex. lasts a day without timezone info f.ex. "New
> Year" is a dateonly event that lasts one day - it everywhere startsat 1.
> january at 0:00 o'clock and ends at 24:00 o'clock  in your current
> timezome. So it a different UTC time for every place at the world. That's
> why you can't replace it with a datetime event, that needs a timezone, so
> it would be wrongly displayed at other timezones.
> The core problem is with that that QDateTime is invalid if either the date
> or the time is invalid. KDateTime is valid also with invalid time. And this
> is behaviour change cannot go into QDateTime, that's why we need anything
> to replace KDateTime.
> The solutions we are were came along at akademy:
> * using QDateTime in a inalid way and check on our own if time&date are
> valid - This approch would lead to many errors, because every application
> must be aware, that qdatetime is used in a "strange way"
> * split the API everywhere into date and time members/functions -> makes it
> much more worse to use the API, because you have to request everytime both
> elements.
> * keep KDateTime  and transform it to an own framework -> this is a very big
> overhead for only one feature

Making it its own framework seems like an odd approach for something which 
seems to be quite a calendar-specific thing. Could you not put an approriate 
class directly into KCalCore? This could basically be KDateTime, or it could 
be something that's basically a union of QDateTime and maybe a QDate?

> As midterm solution we came up to split KDateTime to an own lib inside
> kde4support, so that we can acctually get rid of linking to every other lib,
> that would help to make the start faster and the memory footprint smaller.

This seems like it could be binary incompatible if not done with great care.


More information about the kde-core-devel mailing list