KDED time zone module

David Jarvie lists at astrojar.org.uk
Sun Apr 1 13:16:35 BST 2007


On Saturday 31 March 2007 14:42:32 Thiago Macieira wrote:
> David Jarvie wrote:
> >> 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.

The name is used as the index for looking up the KSystemTimeZone instance so 
that the time zone data can be accessed by applications. And for display 
purposes the local time zone name is needed. Note that if the TZ environment 
variable is set, that is used to obtain the name. Also note that, except on 
Solaris, country codes in zone.tab will usually enable a match to be made 
quickly with /etc/localtime.
 
> >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.

If TZ is set, that gives the local zone name. Non-Linux systems can use 
different schemes - e.g. BSD uses /etc/timezone from which the local time 
zone name can be read directly. The kded module encapsulates these 
system-specific variations.

> >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.

It isn't complex to parse zone.tab. Also, extracting the data from a zoneinfo 
file isn't difficult either. The important thing is not to do it repeatedly 
within a single application, but that's already handled by the time zone 
classes. Taking that into account your other arguments, I think that this 
function of the kded module can be dispensed with.

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




More information about the kde-core-devel mailing list