KDED time zone module

[Thiago Macieira]

David Jarvie wrote:
>> Remember that /etc/localtime must be a copy, not a link. If it's a
>> link, the local time isn't available at boot time if /usr is a
>> mount-point, which in turn means the system clock will be set wrongly
>> if the hardware clock isn't Universal Time.
>
>That explains the use of a copy rather than a link :)  The code for
>determining the local zone (which I didn't write originally) allows for
> a link as one of the options, so perhaps on some systems a link is
> used?

It works too, but I guess only smart installers do that (i.e., they detect 
that /usr isn't a mountpoint).

The default case should be a copy. The drawback of that is that the 
zoneinfo files may get updated, but /etc/localtime won't.

Of course, people should just use UTC in their hardware clocks.

>> But you didn't answer the question: does that information need to be
>> cached? Does it need to be shared via mmap() file?
>>
>> Also, why do we need that information? What are the use cases?

I still don't understand why you need to find which file /etc/localtime is 
a copy from. Can't you simply use it as is?

Or is the point finding out the timezone name? If so, what is the name 
useful for? "Bleh/Foobar" isn't exactly portable.

>1) Virtually every application which uses KDateTime or which uses any
> time zones will reference the local time zone. Currently that includes
> most of the kdepim applications, plus a handful of others such as
> kplato and amarok, but this may well increase as people become more
> aware of the classes. Because of the possible overhead in determining
> the local time zone, it certainly needs to be determined only once per

The local timezone is /etc/localtime or whatever the user set in $TZ. I 
don't see any overhead in determining that.

>3) The function of the kded module which is in more doubt is the
> creation of the KSystemTimeZone collection, since this won't incur the
> same level of processing as items 1 and 2. The kded module needs to
> read and parse zone.tab (which is not a complex operation) to verify
> that the local time zone actually exists on the system. 

What if it doesn't? And see my comments above.

>- The 400+ instances don't have to be created by each application. This
> is probably fairly trivial since the instances are just skeletons
> containing name, location etc.

Agreed. If you are going to parse it and it is a lengthy operation, I 
agree that caching is important. Making it a kded module certainly helps 
with synchronisation and serialisation of the operation.

However, you must be aware that KDateTime is too low-level. This can lead 
to serious deadlocks if KDateTime is allowed to call out to kded at any 
point in time, if somehow the action was triggered by D-Bus/IPC events 
that lead back to kded. The functions that can trigger the call to kded 
should be marked as "possibly lengthy" and should be avoided in call 
paths that can be invoked as a result of D-Bus events.

>- Data can be shared. Once an application has referenced a given time
> zone, its definition data will be read from the zoneinfo directory,
> parsed and stored in the relevant KSystemTimeZone instance. Subsequent
> references even by other applications can use the same data without
> refetching. However, it seems likely that most applications will use
> very few time zones - if so, this may not be significant.

I understand the need for cache. But you have not yet proven to me that 
you need a shared cache file. Is that a lot of data to transfer over, so 
that D-Bus is impractical?

If, however, this data may be required from several points in the 
KDateTime class, using a shared file (with a lock!) is probably better 
than using D-Bus calls. That will be not only faster, but it will also 
avoid deadlocks.

>So the overall advantage is not so clear for this function.

I still don't know what purpose a KDE-local cache of 
the /usr/share/zoneinfo serves.

I understand the need for timezone information, historical even. But given 
that applications will probably not use more than 4 timezones at once, I 
fail to see the need for the cache. Is the parsing of a single timezone 
so expensive?

zdump takes 0.14 seconds here for one timezone. Running "date" takes 0.003 
(and it parses /etc/localtime).

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070331/69151aa0/attachment.sig>