Time zone classes proposal

[David Jarvie]

On Thu Sep 29 22:42 , Shaheed <srhaque at iee.org> sent:

>On Thursday 29 September 2005 15:19, David Jarvie wrote:
>> I have put together the basis of a proposed revision to the KDE time zone
>> classes, approximately along the lines of what I said in my previous
>> posting. The new code is at
>> http://www.astrojar.org.uk/linux/download/ktimezones.h and
>> http://www.astrojar.org.uk/linux/download/ktimezones.cpp. It is based on
>> the old classes, but is substantially different in many respects.
>...
>> Shaheed emailed me 
>> today to say that he has also been revising the time zone code, and he will 
>> no doubt post it here 
>> soon as well. Hopefully after that, we can decide on how to go forward.
>
>As I am going to be unavailable for a while, but don't want to stand in the 
>way of the progress here, I attach my version of the changes. I think I 
>addressed all the specific points originally raised with the exception of 
>improving the "overview" docs - I have not had time to address that. (FWIW, 
>there is *some* there, and there always has been). There is also an updated 
>regression test suite.
>
>I commend this for your perusal.

AFAICS your revisions consist simply of splitting out the system time zone stuff from KTimezones 
into a new class KSystemTimezones. They don't address the issue that the other classes as they 
stand are still not suitable as base classes for implementing access to non-system time zone 
sources. KTimezone and KTimezoneSource are both tied to the system time zones and data formats - 
KTimezoneSource reads data in TZFILE (zoneinfo) format only, while KTimezone methods do 
calculations using tzset() which will only work if the time zone names are known to the system and 
if the definitions of those time zones are the same as the system definitions.

What is needed is a set of classes which can be used for subclassing for use with other sources 
and formats of time zone information, such as iCalendar. My proposals try to address this need, by 
providing a completely general set of base classes which should work (by subclassing) no matter 
what the format of the data, and no matter what the access method (data file, text string, binary 
data, via external library calls, ...).

>Although I have not had a chance to look at David's proposal, I would like to 
>say that I was also concerned by my version of KTimezoneDetails for the 
>reason David suggests. Perhaps his alternate design is more powerful in this 
>regard.

One other detail to note is that my code also fixes the issue of recognising when /etc/localtime 
is a link, and also addresses the problem of re-reading zoneinfo files unnecessarily, by (1) 
checking the file size BEFORE it is opened, and (2) caching the checksums. As Nicolas previously 
pointed out, this is an important issue because of the potentially large numbers of files involved.

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