Date/time class changes to handle extended date ranges

R.F. Pels ruurd at
Mon Feb 20 21:58:00 GMT 2006

On Monday 20 February 2006 19.44, Frans Englich wrote:

>> Frans: now that we landed on that subject, are there any other hiccups
>> with respect to implementing WXS Part 2 datatypes other than
>> QDate/QTime/QDateTime which could be tackled?
> If you want to deal with WXS types via Qt-only you have to add code; how
> much, depends on what you want to do. Let's say, that "given a string I
> want to manually create an instance of the value," then I'd say this is
> needed:
> Extend Qt to accept lexical representations of the types. For example, 1)
> to Qt::DateFormat would be added something like XSDate; 2) QDate would have
> a 'static QDate fromString(const QString &lex, const Qt::DateFormat format,
> bool *ok)' which creates a QDate from a lexical representation of xs:date,
> setting @p ok to false if @p lex doesn't validate.

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.

> QByteArray would have a fromString() function parsing xs:hexBinary and

<huge snip/>

> But this all depends on what demands Trolltech is pleasing. I speculate
> that this basic "value" support is useful to many people, and it also makes
> sense from a technical perspective to put it in Qt. It would to me make
> little sense to let Qt acquire more heavy WXS support such as reading
> Schema files or navigating a type hierarchy.

That indeed depends on wether Qt has a demand for it. 

> If Trolltech has an "XML demand" from customers, I would put basic
> WXS-values support in Qt, and then let kdelibs be the alternative for heavy
> features. XML stacks requires tons of code and it would be nice to have
> that developed the open source way.. This is perhaps a viable solution
> since kdelibs will relatively easy deploy on Windows/OS X.

<nods/> Yes, I agree. Sounds like a plan.

R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at

More information about the kde-core-devel mailing list