Alternative to QDateTime::isDateOnly ?

[Aleix Pol]

On Tue, Apr 28, 2015 at 8:47 PM, John Layt <jlayt at kde.org> wrote:
> On 27 April 2015 at 21:17, Christian Mollekopf <chrigi_1 at 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.