On Monday 03 Aug 2015 18:22:28 you wrote: > 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.
There are a number of cases in kdepim where a date-time or a date can be supplied. Using KDateTime makes the code cleaner - there is no need to provide overloads or to track whether it's date-only when calling multiple layers of functions or classes, because the KDateTime value provides that information. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm