Date/time class changes to handle extended date ranges

[R.F. Pels]

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
> Gregorian.

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