Overflow in QDateTime for extreme values of QDate

In commit 53e6cb3ff676f91a51d55e5740c7174f0c15e390, jon or jonno narrowed the range of Julian day numbers that QDate could support, to limit the range of years to what a 32-bit signed int can represent (because the QDate constructor takes an int year). This is clearly a valid upper bound on the useful range of Julian day values that QDate can work with.

However, QDateTime stores a number of milliseconds, since 1970's start, in a qint64. As it happens,

• 2^{63} ms = 106751991167.3 days = 292277024.6 years
• 2^{31} / 292277024.6 = 7.347

Thus QDateTime can only cope with dates out to less than a seventh of the range that QDate can represent. At present, out-of-range dates lead to overflow in the milliseconds calculation and "valid" date-time objects whose .date() doesn't match what was passed to the constructor. We must, therefore, chose between

• further narrowing the range of dates QDate can represent or
• handling out-of-range dates when constructing a QDateTime.