On Mon, Apr 27, 2015 at 10:17 PM, Christian Mollekopf <chrig...@fastmail.fm> wrote: > Hey, > > 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 > startDateTime() > 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? > > Cheers, > Christian
What about considering the port to be like: QDateTime().time().isNull()? Even QDateTime::isValid documentation mentions that the date and the time need to be valid, therefore the time can be invalid. With that assumption, I'd say we could even implement QDateTime::isDateOnly() or similar. I would most certainly not go into template stuff (i.e. 3, 4 and 5) 2 looks ok but if we get to add the API in Qt, we'll get to port things much more easily. Aleix
