Alternative to QDateTime::isDateOnly ?

[John Layt]

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?

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.