Date/time class changes to handle extended date ranges

[Frans Englich]

On Monday 20 February 2006 13:35, R.F. Pels wrote:
> On Monday 20 February 2006 14.20, Frans Englich wrote:
> > * I would raise the limitation to -9999 to +9999. If you can handle this
> > range you can handle the value space of W3C XML Schema's(WXS) date/time
> > types[1]. It wouldn't surprise me if this is in your interest, since WXS
> > is increasingly used in the industry, and gaining ground in the database
> > community. (for example, my scenarios in XQuery would still need an
> > "ExtDate" class if QDate can't handle that range).
> >
> > Also, I don't see the drawback with an even higher limitation(the more
> > the better). For example, KStars(that's the one using kdeedu's extdate
> > lib, right?) would probably still have to use ExtDate even if QDate went
> > to -9999/9999.
>
> 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).


Cheers,

		Frans