Extended ranges required for dates and date-times

[David Jarvie]

>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. Ideally, QDate would be amended to remove 
the restriction on pre-1752 dates. AFAICS, QDate has no inherent limit of 1752 
and would be able to handle earlier dates simply by removing a pre-1752 
validity check. Frans has put in a request to Trolltech for this limit to be 
removed, but it hasn't been given any priority, so it may well not be done.

Unless Trolltech can be persuaded to do this, we need to implement KDE classes 
to handle extended range dates and date-times. 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. 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.

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.

If the ExtDate classes are made optional, KDateTime would be changed to work 
internally with them, and its interface would be changed to allow either 
QDate/QDateTime or ExtDate/ExtDateTime values to handled. Similar changes 
would be desirable, but not necessarily essential, for other library classes 
too.

Comments?

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