Date/time class changes to handle extended date ranges

[David Jarvie]

There have been no further comments on the "Extended ranges required for dates 
and date-times" subject for a few days, so here are my proposals. They will 
make KDE able to automatically handle Gregorian calendar dates extending back 
50000 years (beyond QDate's semi-arbitrary 1752 limit) and forward 50000 
years (putting to shame Qt's pessimism in assuming that Qt (and by 
implication, KDE?) may be obsolete by the year 8000).

1) Rename KDateTime to KZoneDateTime.

2) Move ExtDate and ExtDateTime from kdeedu into kdecore, and rename them to 
KDate and KDateTime. These will then become the standard KDE classes for 
handling dates and times when time zones don't matter. In order to make them 
a direct plug-in replacement for QDate and QDateTime, they should have 
operator methods added to convert automatically to QDate or QDateTime:
    KDate::operator QDate() const
    KDateTime::operator QDateTime() const
Then, I think, the only methods which differ from QDate/QDateTime are the 
Julian day methods.

3) Convert other kdelibs classes which use QDate and QDateTime to use KDate 
and KDateTime instead. This conversion can be done in stages. I haven't 
looked at the other classes in the ExtDate library - they may also need to be 
merged into kdelibs to replace/modify existing code. I hope that Jason can 
look into that aspect of the changes.

I don't think (unlike Frans) that time zone handling should be included in the 
basic KDateTime class beyond that already present in QTime. IMHO, it's better 
to encapsulate the basic date/time handling in its own KDateTime class, and 
to extend it to time zone handling in a separate class. That way, handling 
date/times without time zones is much easier and less liable to error. And, 
of course, they provide a drop-in replacement for QDate and QDateTime, which 
isn't possible if KDateTime is to include time zone handling.

Frans also suggested a QTime-like class incorporating UTC time offsets. I'm 
not sure how easily this would fit in with the other date/time classes, but 
if it turned out to be something wanted by other people too, it could no 
doubt be added later.

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