Date/time class changes to handle extended date ranges
kde at metafoo.co.uk
Mon Feb 20 01:06:39 GMT 2006
On Sunday 19 February 2006 23:42, R.F. Pels wrote:
> On Sunday 19 February 2006 23.46, David Jarvie wrote:
> > 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().
> Yech! Bletch! As I said earlier, that will lead to boilerplate like
> qdate = kdate.convertToQDateObject();
> if (qdate.isValid() == true)
> // No problem here
> // You are f****d now. If you want to pass that
> // to a method expecting a valid QDate object, go
> // and write a bit of extra code to deal with this
I think you missed David's point. The equivalent code when using QDate only
qdate = some_qdate_i_made_earlier;
// No problem here
// Exactly the same problem as in your code.
It's basically a lot like moving from using a 32-bit integer to a 64-bit
integer. If all the relevant code treats it as a 64-bit integer, then you get
extra precision. If you need to give the number to some code that expects a
32-bit integer, you've gained nothing over using a 32-bit integer all along,
but *you've lost nothing either*. And that's the real point, as far as I can
One case where I can see this causing a problem is if you are getting a KDate
from the user, which you're going to pass to some API which expects a QDate.
Since you used KDate in your GUI (or whatever), your validation code will
most likely do the wrong sort of validation. The solution here is simple and
obvious: you don't actually want a KDate (since that's not what's wanted
downstream), so don't use one, or at least fix your validation code so it
only accepts dates you can handle!
Apart from the clearly-necessary change to the behaviour of isValid(), KDate
sounds like it is a drop-in replacement for QDate in the same way that a long
long is a drop-in replacement for an int.
More information about the kde-core-devel