Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Tue Feb 21 00:23:07 GMT 2006
On Tuesday 21 February 2006 00.40, Frans Englich wrote:
>> These do not necessarily have to be added to QDate, correct? I mean, this
>> could also be part of a connector of some sorts? OTOH, it would be a
>> shame not to make use of datestring parsing already contained in QDate.
>> Hmmm. A QDate /does/ already know how to parse date strings, so adding
>> parsing for xs:date actually does not violate the mandate of QDate.
> Nothing of what I wrote /has/ to be in Qt, except for the extended QDate
> range. However, if you want to create a QDate from a string representation
> of xs:date you must either manually write code for it or extend QDate. It
> depends on how much "out of the box" you want Qt to be for WXS types.
Sorry about that, was merely braindumping... something along the lines of
thinking about string-to-object conversions belonging to the interface of the
class converted to or not and then in the middle of that thought realizing
QDate already does have that included as a method and that representing a
date as a string or interpreting a string as a date has a lot to do with the
concept of date in general. No matter. These types of things have a habit of
flashing through my mind now and again.
> But you are right, it wouldn't be a big change; extending it to parse
> xs:date would be like an accent of Qt::ISODate.
I agree. As is adding the necessary methods to QByteArray and QUrl etcetera. I
would be quite happy if that was added to Qt...
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel