Proposed new KDateTime class

[David Jarvie]

On Thursday 8 December 2005 8:24, Tobias Koenig wrote:
>On Thu, Dec 08, 2005 at 12:10:30AM +0000, David Jarvie wrote:
>> On Wednesday 07 Dec 2005 22:01, Tobias Koenig wrote:
>
>> 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.
>Well, so the external helper class would just pass in the data without
>daylight saving time changes and when this information is not available,
>KTimezone will automatically use the UTC offsets for calculating... or
>do I miss something here?

How does KTimezone know what UTC offsets to use if it doesn't have daylight 
saving time change information?

>Maybe you could summarize shortly which data (timezones, daylight saving
>changes, additional data) may vary in the subclassed KTimezone classes.

There is actually no data common to all KTimezone classes except for the 
mandatory name. The only thing they really have in common is methods to 
access and manipulate times and UTC offsets.

>> It would require a lot of processing for it to call
>> library functions to get a complete list of time changes.
>Yes, so the KSystemTimezone would do... so where is the difference?

KSystemTimezone only calls library functions when it needs to. It would 
generally only ask for one UTC offset for a specific date/time. But to define 
a time zone properly, you need ALL the time changes and UTC offsets (or at 
least those within whatever time period is of interest). This is not 
something which the libc functions are designed to provide.

>> 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.
>What do you mean with other source?

On non-Linux operating systems (particularly Windows which will presumably be 
implemented in the next year or two), there may not be a zonetab database.

>> 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.
>Not a fixed set, but maybe a greatest common factor which can be used in
>KTimezone.

As I explain above, there is no greatest common factor beyond the time zone 
name. And the name depends on the time zone database being used as the source.

>I know this workaround breaks the nice OO way of doing software
>development, however a class which can't be used in most cases (and
>serialization will be an important action in KDEPIM 4.0) is quite
>useless.

I agree that serialisation is important. The problem is how to do it.

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