Extended ranges required for dates and date-times
lists at astrojar.org.uk
Thu Feb 9 14:59:09 GMT 2006
>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
KAlarm author & maintainer.
More information about the kde-core-devel