Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Mon Feb 20 15:10:50 GMT 2006
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
More information about the kde-core-devel