Date/time class changes to handle extended date ranges

David Jarvie lists at
Mon Feb 20 02:05:52 GMT 2006

On Mon Feb 20  1:41 , 'R.F. Pels' <ruurd at> sent:

>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 

Provided, as Richard says, you ensure that the GUI validation takes account of
the precision to which it will ultimately be converted, you *can* go back to a
QDate, for the reasons already stated more than once in other emails.

David Jarvie.
KAlarm author & maintainer.

More information about the kde-core-devel mailing list