Date/time class changes to handle extended date ranges

[Frans Englich]

On Sunday 19 February 2006 22:41, David Jarvie wrote:
> 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.

Hm.. one interesting point is that a QDate becomes invalid no matter if it is 
from an impossible conversion from an KDateTime or if it is set to an invalid 
date. However, using that exceptional "loop-hole" to assert that implicit 
KDateTime to QDateTime conversions are therefore ok in general, is a big 
step, but it's perhaps worth mentioning.


Cheers,

		Frans