2015-08-03 17:33 GMT+03:00 David Jarvie <djar...@kde.org>: > On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote: > >> 2015-08-03 15:26 GMT+03:00 David Jarvie <djar...@kde.org>: > >> > On Monday 03 Aug 2015 12:59:59 you wrote: > >> > > >> >> 2015-08-02 21:32 GMT+03:00 David Jarvie <djar...@kde.org>: > >> > > >> >> > > >> > > >> >> > Date-only KDateTime instances are not only used for Event start/end > >> >> > timestamps. In KAlarm they are also used among other things for alarm > >> >> > snooze > >> >> > times (independently of whether the event is date-only or not). So >> >> > usage > >> >> > of > >> >> > the date-only attribute is *not* restricted to Events (even if that >> >> > is > >> >> > all > >> >> > it is used for in kcalcore). > >> >> > > >> > > >> >> > >> > > >> >> Sorry for injecting myself, but IMO there's no such thing as Date-only >> >> and > >> >> what you need is something like QDateTimeRange (just made up) where you > >> >> would > >> >> have start QDateTime, end QDateTime and it could represent any > >> >> Event/Interval. > >> > > >> >> Like whole day, part of day or even multiple days. And could also check > >> >> whether > >> >> some QDateTime is inside this range. > >> > > >> > > >> > > >> > Date-only extends the current QDateTime concept to allow it to represent >> > a > >> > single date (which is intrinsically a time range) or a single date-time, > >> > without requiring any extra date-time information to be stored - only a > >> > boolean flag is required to indicate whether the time component should >> > be > >> > ignored. > >> > > >> > > >> > > >> > A generalised time range on the other hand requires storing distinct >> > start > >> > and end times, and cannot (except for special cases) be represented by a > >> > single date or date-time. > >> > > >> > >> That sounds like kind of a hack... trying to save few bytes for very > >> minimal use case. > >> As soon as you'll need to represent something outside of that you'll > >> need a proper range. > >> Besides can implement range with QDateTime + qint64 > > > > My point is that a QDateTime already contains both a date and a date-time. A > date-only option provides the option to select one or the other. QDateTime > does not contain a range, so a time range is something different (except for > the special case of a single date). Adding a flag to select data which is > already there is IMHO different in scope from adding extra data (either > another QDateTime or a qint64). >
Ok, I don't really understand what's your use case and so I don't see why you would need that. There's QDate and QTime, you can use QDateTime::date() to extract QDate and for other cases you really do need a range. Sounds like you want QDateOrTime (also made up), but I think very few applications would use something like. And IMO that's bad design, because cleaner code would be with method overloads which take either QDate or QTime.