From kde-core-devel  Thu Dec 08 00:10:30 2005
From: David Jarvie <lists () astrojar ! org ! uk>
Date: Thu, 08 Dec 2005 00:10:30 +0000
To: kde-core-devel
Subject: Re: Proposed new KDateTime class
Message-Id: <200512080010.31544.lists () astrojar ! org ! uk>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113400074623630

On Wednesday 07 Dec 2005 22:01, Tobias Koenig wrote:
> On Tue, Dec 06, 2005 at 06:28:38PM +0000, David Jarvie wrote:
> > On Monday 05 Dec 2005 13:51, Tobias Koenig wrote:
>
> Hi David,
>
> > > Do we really need this flexibility? Which functionality of KTimezone
> > > must be variable exactly? Reading/transforming the timezone
> > > information? Couldn't this be done by an external helper class?
> >
> > What sort of helper class do you envisage?
>
> Well, a helper class which extracts the necessary information from a
> ical file, or system timezone file and sets the value in the KTimezone
> object with a setter method, so the KTimezone method doesn't have to be
> polymorphic.

The problem is that the data held for different time zone classes (because of 
the different types of data in the source databases) varies. For example, for 
KSystemTimezone, the class doesn't actually hold data on daylight savings 
time changes. It gets information as and when required about UTC offsets, 
etc., from library calls. It would require a lot of processing for it to call 
library functions to get a complete list of time changes. If, of course, the 
system library gets its information from the zonetab database, it could read 
the relevant tzfile using the KTzfileTimezone class, and compile a complete 
list of time changes from it. But if the system time zone database comes from 
some other source, there is no obvious solution.

To sum up, there is no fixed set of data belonging to a time zone class. So 
it's difficult to see how to proceed.

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