Date/time class changes to handle extended date ranges

R.F. Pels ruurd at
Mon Feb 20 01:41:41 GMT 2006

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 

R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at

More information about the kde-core-devel mailing list