Date/time class changes to handle extended date ranges

[David Jarvie]

On Saturday 18 February 2006 17:13, Frans Englich wrote:
> On Saturday 18 February 2006 11:58, David Jarvie wrote:
> > 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
>
> Perhaps that needs consideration; it would make it possible to implicitly
> achieve data loss, and the reason KDateTime/KDate is used in the first
> place is for the extended range. For example, let's say a KDate contains
> -3530 years; what is the resulting QDate? Invalid?

Yes. That is an invalid date as far as QDate is concerned, so I think that's 
the reasonable result. If you want extended range dates, don't use QDate.

> > 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.
>
> Out of curiosity, what classes is this?

You can find the full list by grepping kdelibs sources. In addition to 
calendar and time zone classes, KLocale, KConfigBase, KDatePicker, 
KBuildSycoca are examples. Ultimately, all KDE modules probably ought to use 
KDate and KDateTime unless they have some particular reason to use Qt's 
classes. But there's no necessity if they don't want extended range dates.

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