Extended ranges required for dates and date-times
frans.englich at telia.com
Thu Feb 9 16:19:36 GMT 2006
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":
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.
More information about the kde-core-devel