Date/time class changes to handle extended date ranges

[Frans Englich]

On Sunday 19 February 2006 16:03, R.F. Pels wrote:
> 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).

I don't follow you. As pointed out by Jarvie, KDateTime is new, it's one or 
two months old and therefore cannot cause a porting effort. Second, these 
classes will closely mimmic QDate/QDateTime's APIs for all the usual reasons. 
Essentially, the only difference is the range. I don't see how this "depature 
from QDateTime" should hinder its acceptance.

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

You see that this will "certainly lead to trouble", I don't, so you have to 
give examples. It's not about specialization(as in inheritance) because the 
classes won't inherit Qt's. And they won't wrap Qt's classes(such as in the 
meaning of a delegation pattern); KDateTime will have a QTime instance 
internally for handling time, but that's not about the class's role or 
interface.

It's not that controversial. The only change is in range. They still deals 
with Gregorian ranges, and it's about dates and times. E.g, we're still 
driving a car(breaking, turning, etc), the only change is that we've bumped 
the max-speed. The classes have new names(K*), and they are not members of 
QDate/Time's class hierarchy. I don't see the trouble.

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

I understand and sympathize with grief over computers'(and humans in general) 
completely arbitrary and conventional limits. Dates & times are probably one 
of the worst areas.

But this K* proposal does not introduce something new, it only 
stays /consistent/ with existing code and practices. As I see it, the default 
calendar system is already adopted; what we need is an extended gregorian 
range.


Cheers,

		Frans