Date/time class changes to handle extended date ranges
lists at astrojar.org.uk
Mon Feb 20 11:31:58 GMT 2006
On Monday 20 February 2006 10:40, Thiago Macieira wrote:
>R.F. Pels wrote:
>>I think it stinks. If we want an extension of the date range, I think it
>>should be applied on the Qt level. And I'm not seeing that happen
>> anytime soon unless we do the patch-qt-song-and-dance :-(
>What is needed to make QDate work with the extended range? Can you send me
>the patch against Qt 4.1.0 or trunk/qt-copy ?
QDate sets a lower limit of the date in 1752 when the UK adopted the Gregorian
calendar. (And the UK wasn't even the first country to do so, so the limit is a bit
arbitrary!) AFAICS the only reason that QDate rejects dates <= 1752 is the validity
test which it makes when setting its value, and the isValid() method which consists
simply of a test as to whether the date is greater than 1752. If these tests were
removed, it would be capable of handling earlier dates, by my reckoning to 4700 BC
approx. It would also, I think, be capable of extending its upper limit way beyond
the year 7999.
Internally, it holds its date as a day number in an unsigned int. If this was
converted to a signed int, and a day number of 0x80000000 (for example) was used as
an invalid indication in place of the existing validity checks, it would AFAICS do
the same job as ExtDate. We could then continue to use QDate and QDateTime, without
any need to change the kdecore classes. This would be the ideal solution.
I don't have access to my system just now to produce a patch, but I'll try to do so
this evening if nobody else does so before that.
KAlarm author & maintainer.
More information about the kde-core-devel