Date/time class changes to handle extended date ranges

[Guillaume Laurent]

On Monday 20 February 2006 00:34, R.F. Pels wrote:
> 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.

Uh, all string classes (std::string, QString, etc...) have conversions for 
plain old char*. Having KDate providing a toQDate() method makes perfect 
sense to me, even if it can yield an invalid object in some cases.

-- 
Guillaume.
http://www.telegraph-road.org