Date/time class changes to handle extended date ranges

David Jarvie lists at astrojar.org.uk
Mon Feb 20 01:56:04 GMT 2006


On Sun Feb 19 23:34 , 'R.F. Pels' <ruurd at tiscali.nl> sent:

>On Sunday 19 February 2006 23.41, David Jarvie wrote:
>
>> >It's like converting a "long long" to "char": the compiler may let you,
>> >but it'll print a warning. If you want it to shut up because you know
>> >better, you have to explicitly cast.
>> >
>> >This is what classes should do too.
>>
>> In this case, the conversion error *would* be detectable, because the QDate
>> would return isValid() == false. That wouldn't give a compiler error
>> obviously, but wouldn't the isValid() test be sufficient? 
>
>Horribilis! Picture this:
>
>	QDate qdate = kdate.convertToQDate();
>	if (qdate.isValid() == true)
>	{
>	  // OK no problem here
>   	}
>	else
>	{
>	  // Uhoh. Now I'm f****d! How am I going to
> 	  // use this in a method that expects a valid
>	  // QDate object???
>	}

You can't use it in a method that expects a valid QDate object. Which is exactly
the same result as if you had never used a KDate, but had simply used a QDate
instead. So what's the problem?

>> The idea of the conversion casts is that KDate could be made a plugin for
>> QDate. Remember that the two will be equivalent for all dates in the range
>> 1752 - 7999, which covers most uses. Only a few applications are likely to
>> hit dates outside that range.
>
>And that is exactly the reason why this class should not be a QDate 
>specialistion, should not have conversion operators that produce a QDate and 
>should not have a name that could even remotely give the impression that it 
>has something to do with a QDate. This class CAN NOT BE a plugin for QDate 
>because its contract is wider than the contract of QDate.

But you can still detect whether the date is valid once you convert from a KDate
to a QDate. It's the same as Thiago's example of converting from a long long to a
long, but it with the important difference that you can actually determine that
the conversion has failed. And, to repeat once more, the end result is exactly
the same as if you had used QDate all along.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html





More information about the kde-core-devel mailing list