Date/time class changes to handle extended date ranges

[David Jarvie]

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.

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