Alternative to QDateTime::isDateOnly ?

Christian Mollekopf chrigi_1 at
Mon Apr 27 21:17:38 BST 2015


KDateTime used to have a date-only functionality, that QDateTime is
lacking. The problem with that is that we need to find a new solution
for interfaces that allow to set/get either QDate or QDateTime.

One such interface is KCalCore::Event::start(). For the sake of
discussion getters are more interesting, because a simple overload is
not possible. I see the following possible solutions:

1. add isDateOnly functionality to QDateTime
2. Overloads with different names: QDate startDate(), QDateTime
3. Overloads using templates: T start<T>()
4. QVariant that can contain either QDateTime or QDate: QVariant start()
5. boost::variant that can contain either QDateTime or QDate:
boost::variant<QDate, QDateTime> start()

Given that this should be a fairly common porting problem (at least in
the PIM realm), it would be nice to have a standard solution for it.

Opinions following:
1. I'm not sure whether it semantically makes sense to have a QDateTime
without a time. It would make sense to have a PointInTime with higher or
lower accuracy though.
2. Not a solution, but a workaround.
3. Better than 2., but not by much.
4. Would be pretty good IMO, but unfortunately leads to an unexpressive
interface (because QVariant can't be parametrized with valid values).
5. boost::variant solves the problem of 4., and is header-only, but I'm
not sure to what extent boost is accepted in interfaces?

I think the variant solutions are actually not that bad, semantically,
but QVariant seems a bit useless for a case like this.

Any ideas or opinions?


More information about the kde-core-devel mailing list