Replacement for KDateTime

[John Layt]

On 1 August 2015 at 19:47, Sandro Knauß <bugs at sandroknauss.de> wrote:

> * 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.

This is the real problem and the biggest stumbling block,and I'm sorry
I haven't had the time to come up with a solution as promised.  I'll
try sort it out in the next week or so. It was something I wanted in
QTimeZone but it was far to complex to get in the first version., or
indeed maybe ever. I need to see if there's a way we can derive our
own support separate to Qt.

> * 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.

I've been over this before on the PIM list, it's a fundamental mistake
to say that 'Date Only' is an attribute of the datetime, it is in fact
an attribute of the Event itself, and indeed is in the current API as
such.  I fail to see why it needs to be in the datetime as well? If
there is anywhere using the datetime property instead of the Event
property it is doing it wrong, make it check the Event instead. Do not
put it back in the datetime. Use the datetime to represent the valid
start time or endtime of the all day event, i.e. 00:00 in the time
zone of the datetime on which the event starts or finishes.

> * keep KDateTime  and transform it to an own framework -> this is a very big
> overhead for only one feature

You do *not* want to do this, we specifically got rid of KDateTime to
be compatible with Qt and other apps using Qt to attract new users and
devs. If you do this you also need all of KLocale again which we also
do not want. Don't even go there, we changed it for a purpose.

If you plan to release KCalCore as a Framework, then it must be free
of KDateTime and KLocale in the API, otherwise no-one else can use it
and you're locked-in with a bad API.

John.