Alternative to QDateTime::isDateOnly ?

[Christian Mollekopf]

On Tue, Apr 28, 2015, at 08:47 PM, John Layt wrote:
> On 27 April 2015 at 21:17, Christian Mollekopf <chrigi_1 at fastmail.fm>
> wrote:
> 

Hey John,

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

Ok.

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

We don't need a timezone for date-only (AFAIR), but we do need date-time
sometimes.

> 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?
> 

That's seems like too much of a hack for me.

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

Not a bad idea at all...
The end/due date must follow the start date by definition after all.

On the other hand, the problem of the variable return type is not solved
by that,
overloads and separate getters always seemed like a workaround to me,
so it seems like Qt would benefit from something like boost::variant
(aka. a discriminated union)

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

True, a separate Duration class that can either point to a day
(date-only), or a second (date-time)
could be a solution as well.

Thanks for your ideas,

Christian