Alternative to QDateTime::isDateOnly ?

Sandro Knauß knauss at kolabsys.com
Tue Apr 28 22:51:46 BST 2015


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 how would you know when it was really invalid or when it
> was Date Only?

I also think that Aleixs approch is not good, because you can't tell if the 
QDateTime is invaliad at all or a dateonly value. Create a childclass 
QDateTime with a dateOnly attribute and change isValid. If this method is 
virtual, we can also think about designing the API only with the baseclass 
QDateTime and not with the childclass.

> Personally, I suspect relying on the QDateTime to tell you it is Date
> Only is perhaps the wrong approach?

The problem is not how we save the date/datetime internally, therefore we 
could use Aleix aproch (the event has actually the attribute dateonly). The 
problem is interface to the outside world. It would be nice to have an as easy 
interface than possible and for that it would be nice to have only one 
setter/getter for ex. the start attribute. Because if we have no type that 
handles both you have evey time to check expictly and copy code:

if (event.isDateOnly()) {
  QDate date = event.startDate();
  [...]
} else {
  QDateTime datetime = event.startDateTime();
  [...]
}

against:

DATETYPE dateOrDateTime = event.start();
[...]
if (dateOrDateTime.isDateOnly()) {
  [...]
}

But look at usecases, why we need to know if it is a dateOnly datepoint:

* dateonly is shown at over views in calendar (without timezoneinfo it is 
translated to local time)
* enable/disable widgets for time/timezone
* rfc has the difference, so we need to know when we save/load from ical
f.ex.  normally nobody sets bithdays with time, but rfc allows it.
* for a valid time you need for sure a valid timezone otherwise a time doesn't 
make sense.

Regads,

sandro

-- 
Sandro Knauß
Software Developer

Kolab Systems AG
Zürich, Switzerland

e: knauss at kolabsystems.com
t: +41 43 501 66 91
w: https://kolabsystems.com

pgp: CE81539E Sandro Knauß
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150428/e7f1ef6e/attachment.sig>


More information about the kde-core-devel mailing list