Replacement for KDateTime

[Alex Merry]

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.

Alex