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