Date/time class changes to handle extended date ranges

[Frans Englich]

On Monday 20 February 2006 21:58, R.F. Pels wrote:
> 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.

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.

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.


Cheers,

		Frans