Date/time class changes to handle extended date ranges

[Frans Englich]

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?

> 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?

> 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.

Regardless of what I've written before I think that sounds good. People who 
don't need timezone handling aren't penalized by the overhead, etc.

> 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.

It really is a question of cost/benefit. KXPath need time+UTC offset handling, 
and the current KDateTime handles that fine. The only drawback of that is 
inefficiency, and that's what the effort of creating a "KZoneTime" class 
would solve. So, there's no arichtectual problem as I see it, it's more a 
question of investing work in optimization.


Cheers,

		Frans