Date/time class changes to handle extended date ranges

[R.F. Pels]

On Monday 20 February 2006 15.27, Frans Englich wrote:

>> Those are good points. Mind you, the specification of WXS DateTime
>> includes a flag indicating wether it is timezoned.
>
> To be specific, it doesn't got time zones, but zone offsets. And the value
> space is more than a flag, it's typically: 1) whether it have an offset;
> and 2) if so, what the offset is(possibly zero, meaning UTC).
>
>> Now, how are we going to convince TT to add that too because frankly making
>> QDate WXS-compatible is a Good Thing (TM) IMHO.
>
> I fully implement 'WXS Part 2 : Datatypes' by using KDateTime, which brings
> in all that zone offset stuff. Extending QDate/QTime/QDateTime to handle
> zone offset(time zones is not necessary for WXS) would be a relatively big
> feature extension, the classes would enter another area of functionality.
> It wouldn't surprise me if Trolltech in the long run will recieve pressure
> for it though, due to namely the growing database/xml market. Of course,
> such an extension would make me very happy(but it's so distant that I don't
> even dream about it).

Thiago, I'm being a PIG here :-) but want to make sure you read it. This would 
really be very nice! 

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?

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at tiscali.nl       http://home.tiscali.nl/~ruurd