Date/time class changes to handle extended date ranges

[Guillaume Laurent]

R.F. Pels wrote:
> On Monday 20 February 2006 11.29, Guillaume Laurent wrote:
>
>   
>> Oh come on, what kind of hair-splitting is that? Just call
>> convertToQDate() directly and check if the result is valid. An invalid
>> KDate will obviously convert to an invalid QDate, so the first check is
>> pointless. And in practice just how often will you need to convert a
>> KDate to a QDate anyway.
>>     
>
> Anytime I want to use the Qt database classes to stick the value into a 
> database for example.
Granted, but it still won't have to do all those checks you described, just

QDate qdate = kdate.toQDate();
if (qdate.isValid()) { store(qdate); }

which would have been exactly the same no matter how you get the QDate 
from, e.g.

QDate qdate = fetchQDateFromSomewhere();
if (qdate.isValid()) { store(qdate); }

same thing.
> Anytime I want to use KDatePicker, KDateTable, 
> KDateTimeWidget, KDateValidator, KDateWidget and all the places in KDE where 
> a QDate is expected in the interface. A very rough and potentially bad way to 
> count them yielded 600+ places in KDE and several applications where it is 
> used.
>   
I think it's a safe assumption that these classes will be converted to 
use KDate. Not a particularly hard refactoring to do, especially if 
KDate does derive from QDate, while the contrary would make the 
refactoring much more difficult.