Date/time class changes to handle extended date ranges

[David Jarvie]

On Mon Feb 20  1:41 , 'R.F. Pels' <ruurd at tiscali.nl> 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 
>narrowed.

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.
http://www.astrojar.org.uk/linux/kalarm.html