Replacement for KDateTime

[David Jarvie]

On Monday 03 Aug 2015 18:22:28 you wrote:
> 2015-08-03 17:33 GMT+03:00 David Jarvie <djarvie at 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 <djarvie at kde.org>:
> >
> >> > On Monday 03 Aug 2015 12:59:59 you wrote:
> >
> >> >
> >
> >> >> 2015-08-02 21:32 GMT+03:00 David Jarvie <djarvie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150803/bb55ceb5/attachment.htm>