Date/time class changes to handle extended date ranges

[David Jarvie]

On Saturday 18 February 2006 13:03, R.F. Pels wrote:
> On Saturday 18 February 2006 12.58, David Jarvie wrote:
> > 1) Rename KDateTime to KZoneDateTime.
> > 2) Move ExtDate and ExtDateTime from kdeedu into kdecore, and rename them
>
> I think this is a bad move from two points of view:
>
> 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.

> I would gladly support a Calendar like capability in kdelibs, and if the
> extended classes from kdeedu support that, I would think it would be a good
> move to promote those classes to kdelib. In that case, I think they should
> become KGregorianDate and KGregorianDateTime.

The idea is really to provide the same functionality as QDate, but with an 
extended date range. 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.

> That said, I wish to point out that there are different calendars than the
> Gregorian one. How are we supposed to support those in kdelib? FWIW, I wish
> to refer to the java.util.Calendar class.

KDE does provide KCalendar* classes to handle other calendars than the 
Gregorian.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html