Date/time class changes to handle extended date ranges

[David Jarvie]

On Sunday 19 February 2006 19:35, 'R.F. Pels' wrote:
>On Sunday 19 February 2006 19.00, David Jarvie wrote:
>
>> I wasn't aware that there was any such _rule_. It may well be that it's
>> frequently done like that, but there's no reason that I can see to do it
>> slightly differently if it's useful. 
>
>I don't think it is a hard rule. It is more a convention in determining the 
>name of a corresponding K class if any exist. As a matter of fact I myself 
>would be very carefull not to break that convention - especially in a case 
>where the contract of an underlying class is extended such as in this 
>proposal.

As Thiago has said, that is exactly the reason for introducing a new class.

>> How awful! Now dates outside QDate's range will work! That will break lots
>> of applications, I'm sure.
>
>Yep. For example in those parts of Qt where a QDate is used such as the 
>database classes. Drop in a KDate and there is a disconnect. Use a value 
>outside the range offered in the QDate contract and there is a conversion 
>error.

I still don't see the problem. If you construct a QDate with an out-of-range
date, you get an invalid QDate, which the database handles in whatever way it
handles invalid dates. If you use a KDate with a date which is out of range for
QDate, it is implicitly converted to a QDate which is invalid, which is the same
as if you used a QDate all along. If you need to test whether the KDate is a
valid QDate, convert it explicitly to QDate and test with isValid().

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