Extended ranges required for dates and date-times

[Frans Englich]

On Thursday 09 February 2006 14:59, David Jarvie wrote:
> From correspondence with Frans Englich, who is working on implementing W3C
> XML Schema's date/time types for KDOM's XQuery/XSL implementation, it has
> become evident that KDateTime (which provides dates/times along with time
> zone information) needs to be able to handle Gregorian calendar dates for a
> larger date range than QDate allows.
> [...]
> The obvious solution  
> would be to use the ExtDate library classes in kdeedu, which provide dates,
> date-times, date pickers and calendar classes. ExtDate and ExtDateTime
> provide an almost identical interface to that of QDate and QDateTime, and
> handle dates in the range -50000 to 50000.

I think it's important to stress that if we put an extra feature rich date 
class in kdelibs, that it contains the union of all extended-date 
requirements in KDE, such that as much code as possible gains from it.

btw, related is "Bug 89286: date value below 1753":

http://bugs.kde.org/show_bug.cgi?id=89286

Also, I highly doubt that Trolltech will fix/extend QDate to the slightly 
bizarre ranges that is needed in kdeedu: ExtDate goes from -50000 to 50000 
(not that I mind it for my scenarios, of course).

> If it is agreed that these 
> should be moved into kdecore, the following questions arise:
>
> 1)  Should they be made the standard classes in KDE to handle dates and
> date- times, replacing QDate and QDateTime in normal use? Or should they be
> used only where an extended date range is needed, with QDate/QDateTime
> being the standard as currently? The first option has benefit that coders
> wouldn't have to worry about which class to use - they would just always
> use ExtDate etc. The second option has the advantages of less changes to
> current code, and if Trolltech did decide to extend QDate, we could revert
> to using QDate/QDateTime with the minimum of fuss. Extended ranges are only
> needed by a few applications, so making ExtDate standard wouldn't benefit
> most people.

I would say, not more than necessary. As mentioned, it is a minority of 
applications that need this functionality and I don't think specialized 
classes should be pushed on users when they can use simple mainstream code. 
Those applications and APIs/frameworks that needs to handle extended ranges 
can use it.

> 2)  What class names should be used? That would depend on whether the
> ExtDate classes were made the standard KDE classes or not. If so, the names
> KDate and KDateTime would be the obvious ones, which would mean that the
> existing KDateTime which handles time zones as well would have to be
> renamed, perhaps to KZoneDateTime, KDateTimeZone or KDateTimeTZ. If they
> were used as an adjunct to QDate/QDateTime, KExtDate and KExtDateTime might
> be the choice, so that KDateTime's name could be left unchanged.

I wouldn't focus so much on what the classes do. When handling with a date 
value the main point is that it's a date, not that it behind the curtains 
handles large dates in the rare cases it is needed, I think. Therefore, I 
would go for simple names such as KDate instead of KExtDate(and if the latter 
is nevertheless chosen, an easily understandable name such as KExtendedDate).

In short: KDate, as QDate but with extended range; KDateTime, as QDateTime 
with extended range(as KDate) and timezone/zone offset handling.

Of course, as discussed with Jarvie, the "perfect" solution would be something 
in the direction of:

KTime: as QTime plus zone offset handling
KDate: as QDate plus zone offset handling and extended range
KDateTime: as QDateTime plus zone offset handling and extended range

This would be the ultimate solution to what currently is not possible: to 
store only a time or only a date value with zone offset handling(because the 
class that do zone offset handling, KDateTime, stores both date and time). 
But that would require a lot of work.


Cheers,

		Frans