Date/time class changes to handle extended date ranges
lists at astrojar.org.uk
Sat Feb 18 11:58:36 GMT 2006
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.
KAlarm author and maintainer.
More information about the kde-core-devel