Date/time class changes to handle extended date ranges

[David Jarvie]

On Sunday 19 February 2006 20:17, Thiago Macieira wrote:
>R.F. Pels wrote:
>>Hah. In that case I would be very much opposed to adding conversions
>> from KDate to QDate if there is the possibility that one creates an
>> invalid QDate without being able to detect that in an easy way.
>
>That is very much true. If conversion from type A to type B may lose 
>information, it should never be silent. The user has to knowingly do that 
>or get a compiler warning (which is not possible in this case).
>
>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? 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.

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