Date/time class changes to handle extended date ranges

[R.F. Pels]

On Sunday 19 February 2006 19.00, David Jarvie wrote:

> I wasn't aware that there was any such _rule_. It may well be that it's
> frequently done like that, but there's no reason that I can see to do it
> slightly differently if it's useful. 

I don't think it is a hard rule. It is more a convention in determining the 
name of a corresponding K class if any exist. As a matter of fact I myself 
would be very carefull not to break that convention - especially in a case 
where the contract of an underlying class is extended such as in this 
proposal.

> How awful! Now dates outside QDate's range will work! That will break lots
> of applications, I'm sure.

Yep. For example in those parts of Qt where a QDate is used such as the 
database classes. Drop in a KDate and there is a disconnect. Use a value 
outside the range offered in the QDate contract and there is a conversion 
error.

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