Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Sun Feb 19 16:03:17 GMT 2006
On Sunday 19 February 2006 15.51, David Jarvie wrote:
>> 1. Flag day: every unsuspecting user of KDateTime is confronted with
>> a different class with (possibly) a different interface.
>> 2. From the looks of it the new KDateTime all of a sudden looses its
>> capability to handle timezones.
> KDateTime was introduced for KDE 4 and does not exist in KDE 3. The KDE 4
> API is not yet fixed, and anybody coding for KDE 4 should be aware of that.
> So this is not a significant problem, and certainly not a good argument for
> keeping things as they are if there is a good reason to change them.
Well, one of the prime reasons to come up with a better plan is that if the
future KDateTime in its new form is a departure from QDateTime as it is now
will actually hinder porting efforts and hinder its acceptance, IMHO. Doing
this ignores the necessity of enabling a smooth transition from
KDE3/Qt3/Q(Date|DateTime) to KDE4/Qt4/K(Date|DateTime).
> The idea is really to provide the same functionality as QDate, but with an
> extended date range.
Oh yippie, and at the same time introducing incompatibility between the two.
If there is a solid reason to wrap QDate and QDateTime in KDate and
KDateTime, actually enabling the K-classes to have an extended date range
will almost certainly lead to trouble. If it is necessary from a KDE
perspective to wrap them, then wrap them but do not extend the contract that
QDate offers. Extending contracts on specialization is a design flaw.
> QDate of course uses the Gregorian calendar. On the grounds that the
> Gregorian calendar is the de facto world standard, I don't
> think it's unreasonable to call the classes KDate and KDateTime.
Yes it is. This is a very Western-centric idea. As a matter of fact, if this
is one of the reasons to adopt a default calendaring system, we might as well
use the Chinese calendar. Calling a QDate wrapper with an extended contract
KDate creates the wrong expectation.
> KDE does provide KCalendar* classes to handle other calendars than the
If that is the case, I'd prefer that the additional functionality now residing
in the kdeedu package is merged in that class tree.
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel