On 1 August 2015 at 19:47, Sandro Knauß <b...@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.
