KDED time zone module

[David Jarvie]

On Thursday 29 March 2007 14:42, David Faure wrote:
> On Wednesday 28 March 2007, Thiago Macieira wrote:
>> David Jarvie wrote:
>> >Can I assume from what you say that sycoca *is* a suitable storage place
>> > for the data, on the assumption that it is kept in step with the time
>> > zone files?
>>
>> sycoca is used to share data between applications and, sometimes, to
>> cache
>> across sessions.
>>
>> How much CPU impact is this module going to have, on the typical case?
>> Typical case being normal users who care about a single timezone. Maybe
>> receiving the occasional meeting invitation over email with 2 or 3
>> different timezones.
>>
>> Is this module going to parse ALL timezone files? Or just what's needed?
>> (this is to determine if there's a need to cache the parsed data)
>
> It would also be good if kbuildsycoca didn't take 10 minutes for a new
> user...

The module reads zone.tab (or equivalent) to obtain the list of time zones
defined on the system, and creates a KSystemTimeZone instance for each.
The actual time zone definition from the zoneinfo directory is only read
if and when a method requiring it is called on that instance. So if only 2
or 3 different time zones are used by applications during the session,
only details of those 2 or 3 time zones will need to be parsed from the
time zone definition files.

The other function which the module performs is to determine the local
system time zone. Again, the time zone definition file will not be parsed
until an application actually uses it.

The only case where a significant amount of processing may be required at
initialisation is on those systems where the local time definition file
/etc/localtime is held as a copy of, rather than a link to, one of the
zoneinfo files. In this case to determine the identify of the local time
zone, the module has to compare the contents of /etc/localtime with each
of the files in zoneinfo/ until it finds a match. It does this by
computing MD5 checksums and comparing those. However, except on Solaris
zone.tab normally lists the country codes which each time zone applies to.
When this is the case, the search is restricted initially to those time
zones which apply to the country returned by KGlobal::locale()->country(),
which should normally return the local zone very quickly. The very worst
case would require comparisons with all 400+ time zone files.

Caching the local time zone between sessions would eliminate the need for
multiple comparisons except if the local system time zone identity was
changed. It would of course be possible to delay determining the local
time zone until an application needed it, at which point the necessary
processing would kick in, but my preference would be to do this at
initialisation to avoid a possible pause while the files were compared.

The other issue is that on Solaris, there is no zone.tab file listing time
zone summary information. Here, it's necessary to find the line beginning
"Zone" in each time zone file to obtain its summary information. It would
make sense to cache a shared derived zone.tab between sessions so that
this doesn't have to be done on every login by every user.

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