Date/time class changes to handle extended date ranges

[R.F. Pels]

On Monday 20 February 2006 02.06, Richard Smith wrote:

> One case where I can see this causing a problem is if you are getting a
> KDate from the user, which you're going to pass to some API which expects a
> QDate. Since you used KDate in your GUI (or whatever), your validation code
> will most likely do the wrong sort of validation. The solution here is
> simple and obvious: you don't actually want a KDate (since that's not
> what's wanted downstream), so don't use one, or at least fix your
> validation code so it only accepts dates you can handle!
>
> Apart from the clearly-necessary change to the behaviour of isValid(),
> KDate sounds like it is a drop-in replacement for QDate in the same way
> that a long long is a drop-in replacement for an int.

Which it is not, as I explained in earlier posts. You cannot go back to a 
QDate once you choose a KDate because the contract is broadened instead of 
narrowed.

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