On Tue, Apr 28, 2015 at 8:47 PM, John Layt <jl...@kde.org> wrote: > On 27 April 2015 at 21:17, Christian Mollekopf <chrig...@fastmail.fm> wrote: > >> 1. add isDateOnly functionality to QDateTime > ... >> Opinions following: >> 1. I'm not sure whether it semantically makes sense to have a QDateTime >> without a time. > > Adding it to QDateTime was not an option Thiago was happy with so it > didn't make it, It is something only used inside PIM so there's no > wide use-case for it. I do think I could add it fairly easily as a new > internal attribute flag, but it could complicate the code a lot and > I'm also not sure it's possible to do with a backwards compatible > behaviour either. > > Using a QDate in the api is probably not an option for PIM though as > it doesn't have a QTimeZone attached which you will certainly always > need (and yes, that is a reason for doing it in QDateTime). > > One option is the invalid QTime that Aleix mentions. I did have that > in the back of my mind while re-writing QDateTime internals and so > whatever QDate, Qtime and QTimeZone you set should persist in spite of > the QDateTIme overall being invalid. However it's not really a > solution as how would you know when it was really invalid or when it > was Date Only?
Well, it would only be invalid if the date is also invalid then. It would require to change the semantics of ::isValid though, which is probably not accepted at this point anymore. > > Personally, I suspect relying on the QDateTime to tell you it is Date > Only is perhaps the wrong approach? Perhaps it's actually an attribute > of the Event that it is Date Only and not an attribute of the > QDateTime? Rather than checking the QDateTime you've received from a > call to start() to see if it is Date Only, you should be checking if > the Event itself is Date Only? Your setter could have an enum for > choosing, or separate setters for QDate and QDateTime, and then have a > getter for QDateTIme and another for the enum. While this may seem > like a little more work for PIM, it's not used in many places so I > think this may be a better option, and easier to achieve too in the > required timeframe as it's all in your own control. > >> It would make sense to have a PointInTime with higher or >> lower accuracy though. > > I had pondered for a while having that, but with QDateTime internals > now entirely held as milliseconds relative to the Unix epoch and > translated into the QDate and QTime relative to the QTimeZone on the > fly, that's effectively what QDateTime has become. Now, a QDuration > class, or duration mode for QDateTime, could be useful though... > > Cheers! > > John.