[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Date/time class changes to handle extended date ranges
From:       Frans Englich <frans.englich () telia ! com>
Date:       2006-02-20 13:20:00
Message-ID: 200602201320.00226.frans.englich () telia ! com
[Download RAW message or body]

On Monday 20 February 2006 12:06, Thiago Macieira wrote:
> David Jarvie wrote:
> >But if QDate could be amended to allow a greater range of dates, that
> > would be a better solution, as already mentioned in this thread earlier
> > today. Can Trolltech be persuaded to relax the QDate limits?
>
> http://www.trolltech.com/developer/tasktracker.html?method=entry&id=102140
>
> It's scheduled for 4.2.0.

Some comments:

* The reason to QDate's current limitation is, I presume, the interpretation 
problem with early dates. Since you are removing the limit, it could be an 
idea to make the documentation discuss this aspect.

* 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.


Cheers,

		Frans

1.
See:
http://www.w3.org/TR/xmlschema-2/datatypes.html#year-sec-conformance
http://www.w3.org/TR/xmlschema-2/datatypes.html#dateTime
[prev in list] [next in list] [prev in thread] [next in thread]