Date/time class changes to handle extended date ranges
glaurent at telegraph-road.org
Sun Feb 19 23:42:09 GMT 2006
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.
More information about the kde-core-devel