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 mor
On Mon, Apr 27, 2015 at 10:17 PM, Christian Mollekopf
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 interfa
On 27 April 2015 at 21:17, Christian Mollekopf wrote:
> 1. add isDateOnly functionality to QDateTime
...
> Opinions following:
> 1. I'm not sure whether it semantically makes sense to have a QDateTime
> without a time.
Adding it to QDateTime was not an option Thiago was happy with so it
didn't m
On Tue, Apr 28, 2015 at 8:47 PM, John Layt wrote:
> On 27 April 2015 at 21:17, Christian Mollekopf wrote:
>
>> 1. add isDateOnly functionality to QDateTime
> ...
>> Opinions following:
>> 1. I'm not sure whether it semantically makes sense to have a QDateTime
>> without a time.
>
> Adding it to Q
On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
wrote:
> Hey Aleix,
>
>>
>> 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.
>>
>
Hey Aleix,
>
> 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::i
On Tue, Apr 28, 2015, at 08:47 PM, John Layt wrote:
> On 27 April 2015 at 21:17, Christian Mollekopf
> wrote:
>
Hey John,
> > 1. add isDateOnly functionality to QDateTime
> ...
> > Opinions following:
> > 1. I'm not sure whether it semantically makes sense to have a QDateTime
> > without a time
On Wed, Apr 29, 2015, at 12:33 AM, Aleix Pol wrote:
> On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
> wrote:
> >
> > I may be a bit extreme that way, but QDateTime::isValid() would be a
> > blocker
> > for the isDateOnly() functionality IMO.
> >
> >> I would most certainly not go into t
Hey,
> One option is the invalid QTime that Aleix mentions. I did have that
> in the back of my mind while re-writing QDateTime internals and so
> whatever QDate, Qtime and QTimeZone you set should persist in spite of
> the QDateTIme overall being invalid. However it's not really a
> solution as
On Tue, April 28, 2015 9:32 pm, Christian Mollekopf wrote:
> On Tue, Apr 28, 2015, at 08:47 PM, John Layt wrote:
>> On 27 April 2015 at 21:17, Christian Mollekopf
>> wrote:
>>
>
>> Using a QDate in the api is probably not an option for PIM though as
>> it doesn't have a QTimeZone attached which y
On Tuesday 28 April 2015 22:32:12 Christian Mollekopf wrote:
> On the other hand, the problem of the variable return type is not solved
> by that,
> overloads and separate getters always seemed like a workaround to me,
> so it seems like Qt would benefit from something like boost::variant
> (aka. a
Christian Mollekopf wrote:
> 4. Would be pretty good IMO, but unfortunately leads to an unexpressive
> interface (because QVariant can't be parametrized with valid values).
You would just document in the API documentation what types the returned
QVariant can take.
Kevin Kofler
12 matches
Mail list logo
