Replacement for KDateTime

[Dāvis Mosāns]

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.