Date/time class changes to handle extended date ranges

[R.F. Pels]

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???
	}

> 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.

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at tiscali.nl       http://home.tiscali.nl/~ruurd