Date/time class changes to handle extended date ranges
lists at astrojar.org.uk
Sun Feb 19 14:51:48 GMT 2006
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
KAlarm author and maintainer.
More information about the kde-core-devel